perm filename MSG.MSG[COM,LSP]2 blob
sn#864791 filedate 1988-12-02 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂26-Nov-88 1106 MAILER-DAEMON@uc.msc.umn.edu Returned mail: Deferred: Connection refused by hall.cray.com
Received: from uc.msc.umn.edu by SAIL.Stanford.EDU with TCP; 26 Nov 88 11:06:23 PST
Received: by uc.msc.umn.edu (5.59/1.14)
id AA13603; Sat, 26 Nov 88 13:03:36 CDT
Date: Sat, 26 Nov 88 13:03:36 CDT
From: "Mail Delivery Subsystem" <MAILER-DAEMON@uc.msc.umn.edu>
Subject: Returned mail: Deferred: Connection refused by hall.cray.com
Message-Id: <8811261903.AA13603@uc.msc.umn.edu>
To: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
554 <denny@deimos.cray.com>... Unbalanced '<'
554 <denny@deimos.cray.com>... Unbalanced '<'
----- Unsent message follows -----
Received: from sc.msc.umn.edu by uc.msc.umn.edu (5.59/1.14)
id AA01595; Fri, 25 Nov 88 11:30:53 CDT
Return-Path: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU (SAIL.STANFORD.EDU.ARPA) by sc.msc.umn.edu; Fri, 25 Nov 88 11:18:58 cst
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88 09:06:24 PST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03986; 25 Nov 88 14:47 GMT
Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT
Date: Fri, 25 Nov 88 14:46:28 WET
From: Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
To: common-lisp-object-system <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system@sail.stanford.edu>
Cc: common-lisp-object-system-specification-request <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system-specification-request@sail.stanfo
Subject: specification request [plain text]
Reply-To: sheridan@NSS.Cs.Ucl.AC.UK
Message-Id: <8811251448.a025197@sequent.cs.qmc.ac.uk>
I'd like to get an electronic copy of the CLOS spec [including the MetaClass
chapter]. I'd also appreciate any other info. I'm running AAAI-88 PCL
on Coral Common Lisp.
From: flash@cs.qmc.ac.uk (Flash Sheridan)
Reply-To: sheridan@nss.cs.ucl.ac.uk
Portal,MacNet: FlashsMom
∂26-Nov-88 1106 MAILER-DAEMON@hall.cray.com Returned mail: Unable to deliver mail
Received: from uc.msc.umn.edu by SAIL.Stanford.EDU with TCP; 26 Nov 88 11:06:43 PST
Received: from hall.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA13792; Sat, 26 Nov 88 13:03:48 CDT
Received: from uc.msc.umn.edu (umn-rei-uc.arpa) by hall.cray.com
id AB00926; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:45 CST
Date: Sat, 26 Nov 88 13:05:45 CST
From: MAILER-DAEMON@hall.cray.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8811261905.AB00926@hall.cray.com>
To: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
554 <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>... Unbalanced '<'
554 <denny@deimos.cray.com>... Unbalanced '<'
554 <denny@deimos.cray.com>... Unbalanced '<'
----- Unsent message follows -----
Received: from uc.msc.umn.edu (umn-rei-uc.arpa) by hall.cray.com
id AA00921; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:45 CST
Received: from sc.msc.umn.edu by uc.msc.umn.edu (5.59/1.14)
id AA01595; Fri, 25 Nov 88 11:30:53 CDT
Return-Path: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU (SAIL.STANFORD.EDU.ARPA) by sc.msc.umn.edu; Fri, 25 Nov 88 11:18:58 cst
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88 09:06:24 PST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03986; 25 Nov 88 14:47 GMT
Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT
Date: Fri, 25 Nov 88 14:46:28 WET
From: Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
To: common-lisp-object-system <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system@sail.stanford.edu>
Cc: common-lisp-object-system-specification-request <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system-specification-request@sail.stanfo
Subject: specification request [plain text]
Reply-To: sheridan@NSS.Cs.Ucl.AC.UK
Message-Id: <8811251448.a025197@sequent.cs.qmc.ac.uk>
I'd like to get an electronic copy of the CLOS spec [including the MetaClass
chapter]. I'd also appreciate any other info. I'm running AAAI-88 PCL
on Coral Common Lisp.
From: flash@cs.qmc.ac.uk (Flash Sheridan)
Reply-To: sheridan@nss.cs.ucl.ac.uk
Portal,MacNet: FlashsMom
∂26-Nov-88 1106 MAILER-DAEMON@dione.cray.com Returned mail: Unable to deliver mail
Received: from uc.msc.umn.edu by SAIL.Stanford.EDU with TCP; 26 Nov 88 11:06:51 PST
Received: from hall.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA13796; Sat, 26 Nov 88 13:03:55 CDT
Received: from deimos.cray.com by hall.cray.com
id AA00935; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:55 CST
Received: from hall.cray.com by deimos.cray.com
id AB24047; 3.2/CRI-3.6; Sat, 26 Nov 88 13:07:28 CST
Date: Sat, 26 Nov 88 13:07:28 CST
From: MAILER-DAEMON@dione.cray.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8811261907.AB24047@deimos.cray.com>
To: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
554 <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>... Unbalanced '<'
554 denny@dione... Unbalanced '<'
554 denny@dione... Unbalanced '<'
----- Unsent message follows -----
Received: from hall.cray.com by deimos.cray.com
id AA24045; 3.2/CRI-3.6; Sat, 26 Nov 88 13:07:28 CST
Received: from uc.msc.umn.edu (umn-rei-uc.arpa) by hall.cray.com
id AA00921; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:45 CST
Received: from sc.msc.umn.edu by uc.msc.umn.edu (5.59/1.14)
id AA01595; Fri, 25 Nov 88 11:30:53 CDT
Return-Path: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU (SAIL.STANFORD.EDU.ARPA) by sc.msc.umn.edu; Fri, 25 Nov 88 11:18:58 cst
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88 09:06:24 PST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03986; 25 Nov 88 14:47 GMT
Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT
Date: Fri, 25 Nov 88 14:46:28 WET
From: Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
To: common-lisp-object-system <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system@sail.stanford.edu>
Cc: common-lisp-object-system-specification-request <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system-specification-request@sail.stanfo
Subject: specification request [plain text]
Reply-To: sheridan@NSS.Cs.Ucl.AC.UK
Message-Id: <8811251448.a025197@sequent.cs.qmc.ac.uk>
I'd like to get an electronic copy of the CLOS spec [including the MetaClass
chapter]. I'd also appreciate any other info. I'm running AAAI-88 PCL
on Coral Common Lisp.
From: flash@cs.qmc.ac.uk (Flash Sheridan)
Reply-To: sheridan@nss.cs.ucl.ac.uk
Portal,MacNet: FlashsMom
∂26-Nov-88 1106 MAILER-DAEMON@dione.cray.com Returned mail: Unable to deliver mail
Received: from uc.msc.umn.edu by SAIL.Stanford.EDU with TCP; 26 Nov 88 11:06:51 PST
Received: from hall.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA13800; Sat, 26 Nov 88 13:04:00 CDT
Received: from dione.cray.com (dione-gate) by hall.cray.com
id AA00938; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:56 CST
Received: from deimos.cray.com by dione.cray.com
id AB06260; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:46 CST
Date: Sat, 26 Nov 88 13:05:46 CST
From: MAILER-DAEMON@dione.cray.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8811261905.AB06260@dione.cray.com>
To: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
554 <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>... Unbalanced '<'
554 <denny@dione>... Unbalanced '<'
554 <denny@dione>... Unbalanced '<'
----- Unsent message follows -----
Received: from deimos.cray.com by dione.cray.com
id AA06255; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:46 CST
Received: from hall.cray.com by deimos.cray.com
id AA24045; 3.2/CRI-3.6; Sat, 26 Nov 88 13:07:28 CST
Received: from uc.msc.umn.edu (umn-rei-uc.arpa) by hall.cray.com
id AA00921; 3.2/CRI-3.6; Sat, 26 Nov 88 13:05:45 CST
Received: from sc.msc.umn.edu by uc.msc.umn.edu (5.59/1.14)
id AA01595; Fri, 25 Nov 88 11:30:53 CDT
Return-Path: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU (SAIL.STANFORD.EDU.ARPA) by sc.msc.umn.edu; Fri, 25 Nov 88 11:18:58 cst
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88 09:06:24 PST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03986; 25 Nov 88 14:47 GMT
Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT
Date: Fri, 25 Nov 88 14:46:28 WET
From: Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
To: common-lisp-object-system <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system@sail.stanford.edu>
Cc: common-lisp-object-system-specification-request <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system-specification-request@sail.stanfo
Subject: specification request [plain text]
Reply-To: sheridan@NSS.Cs.Ucl.AC.UK
Message-Id: <8811251448.a025197@sequent.cs.qmc.ac.uk>
I'd like to get an electronic copy of the CLOS spec [including the MetaClass
chapter]. I'd also appreciate any other info. I'm running AAAI-88 PCL
on Coral Common Lisp.
From: flash@cs.qmc.ac.uk (Flash Sheridan)
Reply-To: sheridan@nss.cs.ucl.ac.uk
Portal,MacNet: FlashsMom
∂27-Nov-88 0411 mmdf@RELAY.CS.NET Waiting mail (msg.da01788)
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 27 Nov 88 04:11:36 PST
Received: from relay2.cs.net by RELAY.CS.NET id an19515; 27 Nov 88 6:58 EST
Date: Sun, 27 Nov 88 6:45:46 EST
From: RELAY Mail System (MMDF) <mmdf@RELAY.CS.NET>
Sender: mmdf@RELAY.CS.NET
Subject: Waiting mail (msg.da01788)
To: @RELAY.CS.NET:CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
After 5 days (102 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@sorak.kaist.ac.kr:jkim@csd.kaist.ac.kr (host: sorak.kaist.ac.kr) (queue: kaist)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from relay.cs.net by RELAY.CS.NET id da01788; 23 Nov 88 0:37 EST
Received: from sail.stanford.edu by RELAY.CS.NET id aa18955; 22 Nov 88 17:48 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 14:13:35 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 22 Nov 88 14:06:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 295632; 20 Nov 88 17:40:49 EST
Date: Sun, 20 Nov 88 17:30 EST
From: "Robert W. Kerns" <RWK@f.ila.dialnet.symbolics.com>
Subject: How to reach Robert Kerns
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>,
Cris Perdue <cperdue@SUN.COM>
Cc: cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <19881118232718.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19881120223020.0.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Fri, 18 Nov 88 18:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
...
∂28-Nov-88 0746 Mailer failed mail returned
To: Common-Lisp-Object-System-mailer
The following message has expired without successful delivery to recipient(s):
post-common-loops@POTOMAC.ADS.COM
------- Begin undelivered message: -------
25-Nov-88 0907 Common-Lisp-Object-System-mailer specification request [plain text]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88 09:06:24 PST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03986; 25 Nov 88 14:47 GMT
Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT
Date: Fri, 25 Nov 88 14:46:28 WET
From: Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
To: common-lisp-object-system <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system@sail.stanford.edu>
cc: common-lisp-object-system-specification-request <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system-specification-request@sail.stanford.edu>
Subject: specification request [plain text]
Reply-To: sheridan@NSS.Cs.Ucl.AC.UK
Message-ID: <8811251448.a025197@sequent.cs.qmc.ac.uk>
I'd like to get an electronic copy of the CLOS spec [including the MetaClass
chapter]. I'd also appreciate any other info. I'm running AAAI-88 PCL
on Coral Common Lisp.
From: flash@cs.qmc.ac.uk (Flash Sheridan)
Reply-To: sheridan@nss.cs.ucl.ac.uk
Portal,MacNet: FlashsMom
------- End undelivered message -------
∂28-Nov-88 0829 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0829 CL-Compiler-mailer Mystery CL implementation
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:29:38 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:22:30 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296629; 28 Nov 88 11:28:07 EST
Date: Sun, 27 Nov 88 00:02 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Mystery CL implementation
To: Cris Perdue <cperdue@sun.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8811210354.AA02478@clam.sun.com>
Message-Id: <19881127050239.1.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Sun, 20 Nov 88 19:54:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Bob,
I don't understand about this concept of a "mystery" Lisp implementation.
Are you describing an implementation that is on the market?
Or is it really totally secret? Or what? It is important for
me to have it straight which implementations we have received information on.
Hmm. You should realize that as a consultant, under non-disclosure, I
was pushing it to give you that much information. Hence the great air
of mystery, which is somewhat overblown. However, I don't think you
need to worry about duplication. If you want to be sure, you can
forward me a list of implementations you have information on, and I can
check.
------- End undelivered message -------
∂28-Nov-88 0832 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0832 CL-Compiler-mailer Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:08 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:24:57 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296631; 28 Nov 88 11:28:43 EST
Date: Sun, 27 Nov 88 02:19 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
To: Cris Perdue <cperdue@sun.com>, cl-compiler@sail.stanford.edu,
beckerle%clam@sun.com, Moon@riverside.scrc.symbolics.com,
vanroggen%clam@sun.com, gz%clam@sun.com, jmiller%clam@sun.com,
rwk@ai.ai.mit.edu
In-Reply-To: <8811222056.AA04405@clam.sun.com>
Message-Id: <19881127071951.6.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 22 Nov 88 12:56:55 PST
From: cperdue@Sun.COM (Cris Perdue)
Distinct progress, BUT...
I agree with Moon that this is a definition of terms, not a proposal,
yet. I don't think your addition fixes it, either. This is all too
hard to understand. *I* find it confusing, and I've been following
this. It's unclear to me the relationship between "similar as a
constant", "similar at level n", and "similar at level 0".
In fixing it, I think you should first MOTIVATE it, i.e. state the
problem, its costs and its consequences. Then provide a FRAMEWORK or
MODEL in which to understand this, and then tie your definitions to this
framework.
If I gave you this definition:
Carrying capacity: The volume of the trunk.
it sounds like it makes perfect sense, but what if your listener is from
Australia and doesn't know that "trunk" is where you put your luggage,
not your luggage itself, or the proboscis of an pachyderm? He'd
probably figure it out if you told him you were talking about cars, but
he'd have to scratch his bonnet a lot less if you'd explain that you
were trying to decide what kind of car to rent for a trip.
Don't be embarrassed about getting a technical writer to help you.
Technical writing is HARD!
(Note that for cross-compilers it is not always possible to satisfy
this requirement for floating point numbers and complex numbers with
floating point parts. If it is necessary to choose two different
floating point values due to cross-compilation, each value chosen must
be one of the two adjacent, exactly representable numbers such that
the interval between them contains the other number. Other numbers
and characters are represented exactly, so they can be compared if
they are representable on both architecture, an issue for some
characters.)
Why not specify that the result is the same as doing this simple test
program?
(defun cross-compiler-output-float (float stream)
(multiple-value-bind (integer exponent sign)
(integer-decode-float float)
(macrolet ((out (value stream)
`(progn (prin1 ,value ,stream)
(write-char #\space ,stream))))
(out (type-of float) stream)
(out integer stream)
(out exponent stream)
(out sign stream))))
(defun cross-compiler-input-float (stream)
(let ((float-type (read stream))
(integer (read stream))
(exponent (read stream))
(sign (read stream)))
(setq sign (coerce sign float-type))
(scale-float (float integer sign) exponent)))
(defun testit (float)
(let ((string (with-output-to-string (stream)
(cross-compiler-output-float float stream))))
(print string)
(with-input-from-string (stream string)
(cross-compiler-input-float stream))))
This is just the sort of thing that SCALE-FLOAT and INTEGER-DECODE-FLOAT
are intended for! The exact same code works even better when you later
port that cross-compiler to run natively!
The SYMBOL-PLIST, SYMBOL-FUNCTION (or MACRO-FUNCTION), and
SYMBOL-VALUE of a symbol never become immutable as a result of being
in a compiled constant. UNINTERN applies equally to a symbol that
appears in a compiled constant as it does to any other constant.
You mean "any other symbol", not "any other constant", right?
All other objects are similar at level 0.
Huh? Is this saying that all objects of types not mentioned above, are
members of a single equivalence class, and can be coallesced? Perhaps
you mean to say something like this:
Occurrances of all other types of objects are similar at level 0 if the
types are the same.
Even then, this sounds like a backwards way of defining an equivalence
predicate recurively. I'd rather say:
Occurrances of all other types are similar iff they are each of the same
type each of their components listed below are similar.
In other words, it sounds like you're trying to turn a recursive
definition into an iterated one, and then solve the iteration by
induction. Definitely awkward.
Just define the kernal of the recursion, and then define the recursion
step, and leave the "level n" stuff out. At the end of this you notice
that you're defining a "coallesence predicate". Tell the reader that up
front, and he'll understand the recursive definition readily enough.
Similarity at level n, where n>0
--------------------------------
For objects not numbers or characters, and for each of the types
listed below, if either object is of the given type, the two objects
are similar at level n if and only if the other is of that type, and
all of the specified attributes are similar at level n-1.
Also, except where specified otherwise, implementations are permitted
to treat each of the attributes mentioned here as immutable for
objects in compiled constants. It is an error to perform any
operation that would change any attribute listed, on an object in a
compiled constant.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH and ELT for all legal indices.
Don't forget ARRAY-ELEMENT-TYPE of 1-dimentional arrays!
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
The attributes ARRAY-ADJUSTABLE-P, DISPLACED-TO, and
DISPLACED-INDEX (correct names?), may also be made
immutable by implementations.
I think you're saying something compatible with what I suggested, but I
don't find this exposition of it to be very clear.
Structure Slot values, name of structure type (a symbol reference).
I don't think this is sufficient, really. I think it would be safer to
signal an error as a default, unless the user provides information on
how to dump and load them.
This is parallel to arguments Moon made about CLOS instances.
This is also consistent with my view that the print/read syntax of
structures was a serious mistake. (To summarize that view briefly:
They should not have printed readably, and they should not default to
printing all of their elements. If Lisp Machine pathnames were
structures, instead of flavor instances with their own print/read
syntax, you would lose seriously, because they have to be "interned"
by looking them up in a registry.)
Hash-table Keys and values. The table's test is of course unchanged
also. It is an error to compile a constant containing a
an EQ or EQL hash table that has keys that are similar as
constants.
What about size, rehash threshold, etc.? I care more that the standard
explicitly state whether they are preserved, not preserved, or
implementation dependent, than any particular answer.
Function Function constants that are not compiled-functions are
permitted in compiled constants. Two functions are
similar as constants when they are operationally
equivalent. Use of global function bindings, global
macro bindings, and special variables must be considered
external dependencies
What's an "external dependency"?
for this purpose, and constants
appearing in the functions need only be similar as
constants (at level n-1?).
Er, I don't like the idea of supporting such a random subclass of
FUNCTION. Why not just simplify and say that function constants are not
required to be dumped? Remember, there's nothing in CL which gives the
user any control over which functions are definitly NOT compiled
functions!!! There is at least one implementation where the types
FUNCTION and COMPILED-FUNCTION are equivalent.
"A permissible alternative approach is for the evaluator first to
completely compile the form into machine-executable code, and then
invoke the resulting code." -- CLtL, Chapter 20, page 321.
In other words, if don't specify something implementation independent
for compiled functions, the behaviour for objects of type FUNCTION is
inherently implementation dependent.
Current practice:
This appears to be a reasonable approximation to what is done by the
Franz, Lucid, Coral, and Texas Instruments implementations.
Adoption cost:
Not known. Probably moderate. The cost would be to implementors
rather than users since this part of the language is currently
underspecified.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
For aggregate objects there must be some policy on supporting
circular structures and otherwise shared structures. That is not
specified here.
I think it should be.
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
I think it is fine to have some things be explicitly implementation
dependent, so long as this proposal (and the spec) makes it very clear
just which things they are.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
LENGTH and ELT for all legal indices.
[And ARRAY-ELEMENT-TYPE]
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
Why not say that all other attributes of arrays are NOT preserved; the
created array may be a SIMPLE-ARRAY, and it is an error (or whatever the
new terminology is) to reference any array attributes not present in
SIMPLE-ARRAY's?
Note that to say that objects are similar as constants is to say
that they can be coalesced.
What the HELL is this statement doing down here at the end? Er, excuse
me. But that's the reaction you can expect unless you move it, from all
the people who try to figure out what you're talking about. Move this
into the MOTIVATION section I talked about earlier.
Comparing functions is hard.
For some values of "comparing", it is impossible. EQ is possible. If
you try a more liberal definition, you immediately get into difficulty.
One could define an operation that
converts an interpreted function into a lambda expression. One could
say that interpreted functions are similar as constants when their
associated lambda expressions are similar in the appropriate sense.
I dare you to try to nail down "appropriate".
This similarity of lambda expressions would be syntactic, but would
have to allow for possible inline macro expansion.
And don't forget that those macro expansions just might look up one of
their arguments in an EQ hash table and decide what to do based on that.
Or might call RANDOM. Or carry on a dialog with the user, or some
friend on the network, or a stream.
Now, there's a lot to be said for taming macros by defining some things
as being beyond the pale, but until they're tamed, you gotta deal with
the critters.
Other
transformations would have to be prohibited, or the functions would
have to report themselves as compiled.
Which they just might do anyway.
(typep #'(lambda () ()) 'compiled-function)
==> T
in Coral Common Lisp.
This proposal seems to deal with the question of how to test whether
constants in different Lisp address spaces are similar as constants.
That is an important concern.
Again, finding this at the END of the proposal is making me feel dizzy.
"Where's my head?"
"You're standing on it!"
"Oh."
This would subsume isse CONSTANT-ARRAY-ATTRIBUTES if accepted.
------- End undelivered message -------
∂28-Nov-88 0839 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0839 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:38:51 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:31:43 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296647; 28 Nov 88 11:37:25 EST
Date: Sun, 27 Nov 88 03:50 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Cris Perdue <cperdue@sun.com>
Cc: cl-compiler@sail.stanford.edu, beckerle%clam@sun.com, moon%clam@sun.com,
vanroggen%clam@sun.com, gz%clam@sun.com, jmiller%clam@sun.com,
rwk@ai.ai.mit.edu
In-Reply-To: <8811222158.AA08367@defun.utah.edu>
Message-Id: <19881127085004.1.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 22 Nov 88 14:58:08 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
"Equivalent" or "isomorphic" might be more precise terms than
"similar". If we wanted to get theoretical about it, this proposal is
defining an equivalence relationship.
In general, I prefer using the terms "equivalence relationship",
"equivalence set", or "equivalence predicate" when working with this
kind of concept. It's allowed me to understand some pretty hairy stuff
and keep it straight; anything else and I end up translating in my head.
> Hash-table Keys and values. The table's test is of course unchanged
> also. It is an error to compile a constant containing a
> an EQ or EQL hash table that has keys that are similar as
> constants.
If a coalescing is generalized, then EQUAL hash tables will be affected
as well.
Depends on what equivalence predicate you use. And note that there is
NO REQUIREMENT that the coalescence equivalence predicate, and the one
which defines what properties are preserved, be the same predicate!
I strongly suggest EQL as the coalescence predicate.
> Note that to say that objects are similar as constants is to say
> that they can be coalesced.
I believe this is the right thing to do, but it probably ought to be
considered separately since it is a change (rather than a
clarification) to the language. I was going to write up a new version
of issue CONSTANT-COLLAPSING to deal with this explicitly.
I agree that what we've been discussing is clarification, not change.
But chosing EQL as the coalescence predicate (we have to have one, if
only EQ) I don't think would be a change. I don't think we can discuss
these completely separately.
We probably do have to vote on them separately, but we have to remember
that they interact. As this proposal is written, logic dictates EQL as
the coalescence predicate.
------- End undelivered message -------
∂28-Nov-88 0838 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0838 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:37:55 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:30:46 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296645; 28 Nov 88 11:36:31 EST
Date: Sun, 27 Nov 88 00:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
To: David N Gray <Gray@dsg.csc.ti.com>, Cris Perdue <cperdue@sun.com>
Cc: cl-compiler@sail.stanford.edu, beckerle%clam@sun.com, moon%clam@sun.com,
vanroggen%clam@sun.com, gz%clam@sun.com, jmiller%clam@sun.com,
rwk@ai.ai.mit.edu
In-Reply-To: <2805229894-979699@Kelvin>
Message-Id: <19881127054212.5.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 22 Nov 88 16:31:34 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> If a symbol is not interned, i.e. its home package is NIL, it is
> similar as a constant to any symbol with the same name and no home
> package. In addition, all occurrences of the same uninterned symbol
> in the same constant expression must be EQ after file-compilation and
> loading. Uninterned symbols not EQ at compile time must never be
> coalesced by file-compilation and loading.
The first and third sentences above seem to be contradictory. I believe
the third sentence is the correct one. Test case:
(EQ '#.(MAKE-SYMBOL "FOO") '#.(MAKE-SYMBOL "FOO")) => NIL
Right. But also, I don't think the second sentence there is
sufficiently clear. I think the following example helps.
(eval-when (eval compile)
;; Create an uninterned symbol which we'll use in several ways,
;; all of which must remain EQ, when compiled.
(setq *my-marker* (make-symbol "MY MARKER")))
(defvar *marker-a* '#.*my-marker*)
(defun test-it-1 (&optional (marker *marker-a*))
(eq '#.*my-marker* marker))
(format t "~&Test 1 ~A."
(if (test-it-1) "passed" "failed"))
(defun test-it-2 ()
(test-it-1 '#.*my-marker*))
(format t "~&Test 2 ~A."
(if (test-it-2) "passed" "failed"))
(defmacro test-it-3a ()
`'#.*my-marker*)
(defun test-it-3 ()
(test-it-1 (test-it-3a)))
(format t "~&Test 3 ~A."
(if (test-it-3) "passed" "failed"))
------- End undelivered message -------
∂28-Nov-88 0837 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0837 CL-Compiler-mailer Objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:37:16 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:30:03 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296636; 28 Nov 88 11:33:09 EST
Date: Sun, 27 Nov 88 03:39 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Objects in quoted constants
To: Jon L White <jonl@lucid.com>, cperdue@sun.com
Cc: cl-compiler@sail.stanford.edu, RWK@ai.ai.mit.edu
In-Reply-To: <8811220246.AA14952@bhopal>
Message-Id: <19881127083914.0.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Mon, 21 Nov 88 18:46:27 PST
From: Jon L White <jonl@lucid.com>
[I'm really replying to RWK]
Re: The only think[sic]
That REALLY sounds like a hiccup!
dumping and loading an immutable object with fill
pointer accomplishes is preserving the full COMPLEXITY of the
implementation of the object, and does not add anything to the MEANING
of the object.
Suppose we substituted CORRECTNESS for COMPLEXITY in your statement? How
would the meaning be affected?
Since we're defining an area of the language where no definition already
exists, we are in effect defining what a correct program may depend on.
We have to make a choice as to whether your example is a correct
(portable) program or not. My choice is that it is not. I infer your
choice is that it is correct. But we have to make a choice somewhere.
I submit that we should make the choice to retain MORE information than
doing PRINT/READ, but LESS information than doing
DISK-SAVE-THE-ENTIRE-ADDRESS-SPACE.
Right now, PRINT/READ doesn't save either the fill pointer or the
element-type (for most values of element-type). It also doesn't save
symbol values, or symbol functions, or symbol plists, or type
defintions, or anything else associated with a symbol.
In fact, there *ARE* implementations which communicate their constants
by PRINT/READ, so anything beyond what PRINT/READ convey *WILL BE A
SIGNIFICANT BURDEN FOR THOSE LISPS*. It's not just FRANZ Lisp; KCL and
its descendants seem to have caught the disease from FRANZ. (Lest
anybody be confused, I'm not talking about Franz, Inc's product here,
I'm talking about a pre-Common-Lisp done at UCB. There's a connection,
but it's not relevant to this.)
And I don't think *ANY* dumper implementation is going to know that my
list-based MOLECULE data structure is supposed to be interned in a table
of known molecules. So my program will blow out trying to do
(MOLECULE-DESCRIPTOR-NAME (GETHASH MOLECULE *MOLECULE-TABLE*))
Not to mention that the array, and my lists, started out being SETFable,
and ended up non-SETFable. That's a lot more drastic than a
fill-pointer going away.
In other words, transfering data between Lisp's is always an information
losing process. The goal of this exercise is not to to copy ALL the
information we can find to copy, because a program MIGHT depend on them.
Instead, it is to SPECIFY a set of rules that if a programmer follows
them, (and the implementer implements them according to spec) he can
write portable programs. A secondary, but important, goal is that this
set of rules result in practical programs without hard-to-live-with
restrictions. And a tertiary, but still very important goal, is that
the rules be clear, understandable, and memorable.
The guiding principles I've used in making my choices are:
0) It's gotta be specified, either as being preserved, or as not
necessarily preserved. A program may either rely on it, or not
rely on it.
1) If PRINT/READ preserves it, dump/load must preserve it.
2) If EQUAL or EQUALP pay attention to it, it's part of the top-level
model of the object and must be dumped.
3) Collections of data (i.e. arrays, lists, pathnames, and hash-tables)
must preserve the data items for retrieval. I am distinguishing
data items here from control or implementation parameters.
4) Item 3 also applies to structures in the abstract, but the meaning
of "preservation" is up to the user.
5) Convey less information, rather than more, when it leads to a more
abstract view of an object. It is the high-level view of objects
which are preserved by PRINT/READ, and by dump/load.
Actually, it's a bit of a lie to call these my "guiding principles".
I've derived them post facto, so you may find discrepencies between my
stated position and my condenced principles. Most likely it would be my
"principles" which would change, but any discrepencies you find are
worth discussing.
As for your example: I claim you are violating the modularity of the
ARRAY type, by depending on the fill-pointer after dumping and
restoring. You're using the fill-pointer as a convenient place to store
an additional piece of data in your data structure, to avoid having a
real "data structure". Note your jury-rigged type predicate in
FIND-OCCLUDED-ELEMENT. The FILL-POINTER is part of a different
protocol, that of VECTOR-PUSH, VECTOR-POP, ELT, LENGTH, and a lot of
sequence & related functions which build on these.
Common Lisp specifies the FILL-POINTER well enough that you can violate
the contract like this so long as you are talking about arrays which are
the same EQ array you created, and not something from, say, COPY-SEQ, or
PRINT/READ, ... or dump/load. To extend this contract to arrays copied
by dump/load is an *EXTENSION TO COMMON LISP*. There is nothing in the
language which suggests to the reader that this is a property of
fill-pointers that he can depend on.
The converse is also true: there's nothing in the language which
suggests to the reader that this is a property of fill pointers he CAN'T
depend on. But thinking that way doesn't lead to portable programs.
Unfortunately, you have to think that way at least some of the time,
because there's nothing in the language that makes you think NUMBERS or
SYMBOLS or anything else will reasonably survive the dumper/loader
process, either.
By my rule 5 above, I am opposed to your "extension" to the language to
preserve fill pointers. But that's the weakest of the rules; it's not
an unworkable extension. I'm willing to go with the flow, if that's
really where the flow goes, but I don't want us to include the
fill-pointer "just because it's there".
------- End undelivered message -------
∂28-Nov-88 0858 MAILER-DAEMON@spice.cs.cmu.edu Unable to deliver mail
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:58:41 PST
Date: Mon, 28 Nov 88 11:56:02 EST
From: MAILER-DAEMON@spice.cs.cmu.edu
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Unable to deliver mail
----- Transcript of session follows -----
joseph.ginder... User unknown
----- Unsent message follows -----
Received: from SAIL.STANFORD.EDU by SPICE.CS.CMU.EDU; 28 Nov 88 11:55:01 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂28-Nov-88 0832 Mailer failed mail returned
To: CL-Object-Oriented-Programming-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
allen@F.BBN.COM; mklein@B.CS.UIUC.EDU; commonlisp@GSWD-VMS.ARPA; CLEMENSON@ECLA.USC.EDU; FIKES@ECLA.USC.EDU
Here is how the remote host(s) replied to these mail addresses:
kcquayle@BBN.COM
451 Nameserver timeout during parsing
mklein@B.CS.UIUC.EDU
554 <mklein@B.CS.UIUC.EDU>... 550 User unknown
------- Begin undelivered message: -------
28-Nov-88 0832 CL-Object-Oriented-Programming-mailer Standard-objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
------- End undelivered message -------
∂28-Nov-88 0905 MAILER-DAEMON%hpdstma@sde.hp.com Returned mail: unknown mailer error 1
Received: from sde.hp.com (hp-sde.sde.hp.com) by SAIL.Stanford.EDU with TCP; 28 Nov 88 09:05:45 PST
Received: from hpdstma.hp.com by hp-sde ; Mon, 28 Nov 88 09:07:38 pst
Received: from hplms2.hpl.hp.com by hpdstma ; Mon, 28 Nov 88 08:48:20 pst
Date: Sun, 27 Nov 88 02:20 EST
From: Mail Delivery Subsystem <MAILER-DAEMON%hpdstma@sde.hp.com>
Subject: Returned mail: unknown mailer error 1
Message-Id: <8811281648.AA26008@hpdstma.hp.com>
To: <CL-Object-Oriented-Programming-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
554 <dsouza@hpdstma>... unknown mailer error 1
554 <dsouza@hpdstma>... unknown mailer error 1
----- Unsent message follows -----
Return-Path: <CL-Object-Oriented-Programming-mailer@SAIL.Stanford.EDU>
Received: from SAIL.Stanford.EDU (SAIL.STANFORD.EDU) by hplms2.hp.com; Mon, 28 Nov 88 08:49:04 pst
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂28-Nov-88 0926 Mailer@G.BBN.COM Message of 28-Nov-88 12:25:04
Received: from G.BBN.COM (CCY.BBN.COM) by SAIL.Stanford.EDU with TCP; 28 Nov 88 09:26:09 PST
Date: Mon 28 Nov 88 12:25:38-EST
From: The Mailer Daemon <Mailer@G.BBN.COM>
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Message of 28-Nov-88 12:25:04
Message failed for the following:
kcquayle@BBN.COM.#Internet: 550 (USER) Unknown user name in "kcquayle@BBN.COM"
------------
Received: from SAIL.STANFORD.EDU by G.BBN.COM; Mon 28 Nov 88 12:25:08-EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
-------
∂28-Nov-88 0930 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0930 CL-Cleanup-mailer Issue: SETF-PLACES (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 09:30:40 PST
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00455g; Mon, 28 Nov 88 09:28:28 PST
Received: by rainbow-warrior id AA10535g; Mon, 28 Nov 88 09:29:57 PST
Date: Mon, 28 Nov 88 09:29:57 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8811281729.AA10535@rainbow-warrior>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 22 Nov 88 19:49 EST <19881123004923.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: SETF-PLACES (version 1)
Date: Tue, 22 Nov 88 19:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I am not happy with this proposal, because I think it is excessively
complicated. I still prefer the SETF-FUNCTION-VS-MACRO proposal.
However, I would rather accept this kludge than not have CLOS at all, so
if X3J13 is adamantly against SETF-FUNCTION-VS-MACRO I will accept this
proposal.
I have the same feelings about it. Having my name associated with it does not
mean that I like it, only that I helped debug it, and that I am not ready to
remove SETF specs from CLOS.
I would prefer to see X3J13 allowed to vote on both proposals
as alternatives, since it's possible that when they see this one they
would prefer the one they rejected before.
I think we should do that.
Note: I am not complaining about the writeup of the proposal, which
is quite clear, but about the substance of the proposal. I believe
the distinction between "specs" and "underlying names" is confusing
and unnecessary. Evidently that is a minority position.
Given the amount of feedback, it is too early to tell if it is a minority
position.
Patrick.
------- End undelivered message -------
∂28-Nov-88 0954 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 0954 CL-Compiler-mailer Compilation issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 09:54:00 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498471; Mon 28-Nov-88 12:47:16 EST
Date: Mon, 28 Nov 88 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Compilation issues
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <881128124718.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
I still have severe problems with a number of the issues on the table.
Among them CONSTANT-COMPILABLE-TYPES, CONSTANT-CIRCULAR-COMPILATION,
CONSTANT-MODIFICATION, and CONSTANT-ARRAY-ATTRIBUTES.
My biggest beef is that people are not doing a good job of describing the
problem before they try to solve it. There's been too much mail about
solutions to problems which haven't been adequately justified.
I almost wish we'd not even permit a proposal to be submitted until we
get consensus on a problem statement for a topic...
In particular, this whole business of needing constants seen by EVAL
and/or the in-core compiler to get moved to pure space is nonsense. I'm
happy to see that done if it can be done by a robust piece of code that
does not run into trouble. But if you start telling me that some random
copier frob which I don't want in the first place is incapable of
recognizing certain cases (like circularities) and dealing with them
gracefully and that therefore I should not use circularities in quoted
constants given to EVAL or to the COMPILE function, then you better
motivate why. Compilers exist for my benefit, not vice versa. I will not
be slave to an utterly random and quite questionable set of optimizations
that people seem to want to put in without clear justification.
If file compilers have problems, let's describe those problems and then
fix them. But in-core compilers do not have most of the problems that
file compilers have, so if you want to propose changing those in -any-
way, you'd better describe clearly what problem you want to fix, and
motivate clearly why your solution is worth the incompatible change you'll
be proposing.
By the way, there seems to be a misconception that coalescing needs to
be done by the compiler. In fact, it -could- be done by the loader.
It was in Maclisp, for example. Whether it's done by one or the other
is invisible to the user, but it is not fair to say that "#," stuff
could not be coalesced because the compiler can't see what it will be.
It might be that the loader does the coalescing. Normally, this would
be an invisible distinction because only with "#," can you tell the
distinction. The thing that really to gets me is not the misconception
as the willingness of this discussion group to seriously entertain an
arguments that presuppose all manner of strange assumptions about
implementation. This is happening -way- too much.
Also, there's far too much implicit interdependence of issues. People
are assuming "#," is gone and that LOAD-TIME-VALUE is in, and so on. In
fact, I recall no such vote and I don't like the idea that we're following
down a number of lines of discussion on the assumption that we'll have
a particular set of primitives with a particular set of characteristics
without saying so explicitly. I've seen comments like "Well, if we have
xxx then that's not an issue." The fact is that in many cases we don't have
the xxx, and the truncated path may turn out to have been important.
We need to keep our assumptions explicit. This is all the more important
because later on you may want to go back and review something (either an
actual proposal or a piece of mail about a proposal) and you may not
know what assumptions influenced the writing when it's no longer current.
Finally, I hope that before any letter ballot is mailed, we will
notified of the date that such a mailing might go out and a list of
likely candidates so that we can prioiritize our last minute responses
to address those issues which are serious candidates in the mind of
whoever constructs the letter ballot (presumably Sandra?) and not waste
time on issues which that individual doesn't see as ripe for vote.
------- End undelivered message -------
∂28-Nov-88 1001 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1001 CL-Compiler-mailer Issue: FILE-COMPILATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 10:00:53 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498479; Mon 28-Nov-88 13:00:49 EST
Date: Mon, 28 Nov 88 13:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FILE-COMPILATION (Version 1)
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <881128130049.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
As a straw man, here's something of a shape I'm more comfortable discussing
for a file compiler cleanup.
Even if people disagree with particular points in this, I stand by my belief
that the general form of this presentation is superior to the much longer
proposals which it seeks to replace. In particular, I didn't want to get
caught up in a lot of mathematical-looking mumbo jumbo about types if it
wasn't going to buy us anything.
----
Issue: FILE-COMPILATION
References: CLtL pp. 56, 77-80, 324
Category: CLARIFICATION/CHANGE
Edit history: 22-Nov-88, Version 1 by Pitman
Subsumes-Issues: CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION,
CONSTANT-MODIFICATION,
CONSTANT-ARRAY-ATTRIBUTES
Status: DRAFT
Problem description:
The target environment of code compiled by the COMPILE function is the
same environment in which the compilation occurred, while the target
environment of COMPILE-FILE is not. As such, it is possible to reliably
preserve object identity and sharing (under EQL) of constants occurring
in programs processed by COMPILE.
The target environment of code compiled by the COMPILE-FILE function
may be very different than the environment in which the compilation
occurred. As such, it is not generally possible to reliably preserve
object identity or sharing (under EQL) of constants occurring in
programs processed by COMPILE-FILE.
It is important to answer the question: What kinds of constants are
permitted in functions to be compiled by COMPILE-FILE, and what aspects
of those constants will be preserved through the process?
Note: If the kinds of constants which COMPILE-FILE can process is a
subset of the kinds of constants which COMPILE could process, a
secondary question might be posed: Should an artificial restriction
be imposed on COMPILE to make the set of constants it permits consistent
with those permitted by COMPILE-FILE, or should COMPILE be allowed to
permit other kinds of constants (either because this leads to interesting
applications or for reasons of backward compatibility)? It should be
clear that this secondary question is beyond the scope of the problem
which this proposal seeks to address.
Proposal (FILE-COMPILATION:STATUS-QUO):
Except as otherwise specified explicitly here, clarify that the only
property of a quoted or self-evaluating constant which the compiler
is required to preserve is EQUAL. That is, if two constants X and Y
were EQUAL before file compilation, they will be EQUAL afterward.
Since constants are not modifiable, this property does not change
as execution proceeds.
[Although the function EQUAL is strictly not defined on circular
structures, one could imagine a version of EQUAL which recognized
circularities and treated them appropriately. For purposes of this
discussion, the kind of EQUAL equality discussed here will be
assumed to include circularities of all kinds of aggregate data
structures: conses, arrays, hash-tables, structures, etc.]
The following types of objects may be used freely as constants, and
their identity (under EQUAL) will be preserved:
- Numbers
- Characters
- Pathnames
Some other types may also be freely used, but care must be taken that
they are not subsequently modified since splitting or coalescing by
the compiler may have occurred and since the effects of side-effects
may not be well-defined. They are:
Type Sample safe operations Sample unsafe operations
Conses CAR, NTHCDR SETF of CAR, NCONC
Arrays AREF, LENGTH SETF of AREF, VECTOR-PUSH
Hash Tables GETHASH, MAPHASH SETF of GETHASH, CLRHASH
Random States MAKE-RANDOM-STATE RANDOM
Structures slot accessor SETF of slot accessor
Standard Objects SLOT-VALUE SETF of SLOT-VALUE
Note that in the case of structures, the definition of the structure type
will not be preserved explicitly and is expected to have been loaded or
otherwise instantiated by the time the loader tries to construct the
a saved structure.
Some objects which are interned will not be preserved explicitly.
Instead, information about how to find them in the new environment will
be saved. For these kinds of objects, it is important that the
structures necessary to intern them be in place already. The following
types of objects may be freely used as objects and their identities
(under EQ) will be preserved using the techniques described:
- Interned symbols. References to a symbol, S, will cause the loader
to execute the equivalent of the expression resulting from
`(INTERN ',(SYMBOL-NAME S) ',(SYMBOL-PACKAGE S))
Note that, strictly, symbols with a null home package are not
necessarily uninterned and symbols with a non-null home package
are not necessarily interned, but by convention they are. For
consistency across implementations, this will be the discrimination
strategy that is used.
- Installed Packages. References to a package, P, will cause the
loader to execute the equivalent of the expression resulting from
`(FIND-PACKAGE ',(PACKAGE-NAME P))
Use of the following kinds of objects as self-evaluating or quoted
constants in code to be processed by the compiler is an error:
- Uninterned symbols
- Deleted packages
- Readtables
- Streams
- Functions (including generic functions)
Rationale:
This preserves what users of most implementations probably see as
the status quo.
Current practice:
...???...
Cost to Imlementors:
Small to moderate.
Although this reflects the approximate status quo from the user side,
some implementations may deviate slightly might need to fix a few
things to come in line.
The most likely thing that could have to change in an implementation was
circularity recognition in the compiled file dumper.
Cost to Users:
Any serious portable code is probably already compatible with this
proposal.
Non-portable code may be affected slightly.
Benefits:
Programmers would be able to more comfortably exploit quoted constants
in some situations where they must currently tread lightly.
Aesthetics:
Most programmers will probably see any attempt to be specific about what
kinds of constants are permitted (or not permitted) as an improvement.
Discussion:
...???...
------- End undelivered message -------
∂28-Nov-88 1043 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1043 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 10:43:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA11586; Mon, 28 Nov 88 11:41:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11420; Mon, 28 Nov 88 11:41:02 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811281841.AA11420@defun.utah.edu>
Date: Mon, 28 Nov 88 11:41:00 MST
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
To: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Cris Perdue <cperdue@sun.com>, cl-compiler@sail.stanford.edu,
beckerle%clam@sun.com, moon%clam@sun.com, vanroggen%clam@sun.com,
gz%clam@sun.com, jmiller%clam@sun.com, rwk@ai.ai.mit.edu
In-Reply-To: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>, Sun, 27 Nov 88 03:50 EST
> Date: Sun, 27 Nov 88 03:50 EST
> From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
>
> ....note that there is
> NO REQUIREMENT that the coalescence equivalence predicate, and the one
> which defines what properties are preserved, be the same predicate!
I agree with this, however it is convenient for them to be the same.
> As this proposal is written, logic dictates EQL as
> the coalescence predicate.
You'll have to spell out your argument in more detail. Maybe it's just
because it's Monday :-(, but it's not at all obvious to me.
Trying to be slightly formal with this again, the proposal defines a
relation between the set of constants in the compiler's environment and
a set of constants in the loader's environment. The relationship
guarantees that any constants that are equivalent in the compiler's
environment will also be equivalent in the loader's environment.
What the proposal does not address is whether the same constant in the
compiler's environment must always map into the same constant in the
loader's environment (i.e., preservation of shared structure), and
vice versa (coalescing of constants). The most general situation is
if we specify that the coalescence predicate should be the same as the
relationship that defines the equivalence classes. Specifying it to
be EQL would essentially force the relationship to be monotonic --
each object in the loader's environment must correspond to exactly one
object in the compiler's environment.
I'd argue for generalizing because it makes more sense to use the
compile/load equivalence relationship instead of EQUAL as the coalescing
predicate, and current practice is on the side of allowing coalescing
rather than disallowing it.
-Sandra
-------
------- End undelivered message -------
∂28-Nov-88 1126 Postmaster@aramis.rutgers.edu Returned mail: Host unknown
Received: from aramis.rutgers.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:24:28 PST
Received: from SAIL.STANFORD.EDU by aramis.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA18145; Mon, 28 Nov 88 14:22:29 EST
Date: Mon, 28 Nov 88 14:22:29 EST
From: Postmaster@aramis.rutgers.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811281922.AA18145@aramis.rutgers.edu>
To: <CL-Object-Oriented-Programming-mailer@sail.stanford.edu>
----- Transcript of session follows -----
550 bylander%osu-20@ohio-state.arpa... Host unknown
----- Unsent message follows -----
Received: from SAIL.STANFORD.EDU by aramis.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA18139; Mon, 28 Nov 88 14:22:29 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂28-Nov-88 1118 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1118 CL-Cleanup-mailer dispatch macro characters
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:18:24 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 28 Nov 88 14:15:59 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 28 Nov 88 14:16:06 EST
Date: Mon, 28 Nov 88 14:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: dispatch macro characters
To: cl-cleanup@sail.stanford.edu
Message-Id: <19881128191527.1.BARMAR@OCCAM.THINK.COM>
Have there been any cleanup issues regarding dispatch macro characters?
I'm reviewing the draft section on I/O, and I noticed some things
weren't specified very completely in this area:
1) What does GET-MACRO-CHARACTER return if the character is a
dispatching character? Currently, I guess it is implementation-defined
by default; should the standard say so explicitly?
2) Is there a way to find out if a character is a dispatching character?
3) If not, what is the effect of calling MAKE-DISPATCH-MACRO-CHARACTER
on a character that is already a dispatch macro character. Is it a
no-op, does it reinitialize its dispatch table, or is it undefined?
If the answer to 2 is "No" and 3 is not "no-op" then it becomes
difficult to call SET-DISPATCH-MACRO-CHARACTER in many situations,
because some other program (or the user) may have turned a dispatch
character into a normal character when the application wasn't looking.
Have there been any cleanup issues addressing these problems?
barmar
------- End undelivered message -------
∂28-Nov-88 1128 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1128 CL-Compiler-mailer mail ballot
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:28:02 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA13740; Mon, 28 Nov 88 12:27:31 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11461; Mon, 28 Nov 88 12:27:24 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811281927.AA11461@defun.utah.edu>
Date: Mon, 28 Nov 88 12:27:23 MST
Subject: mail ballot
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 28 Nov 88 12:47 EST
Unless somebody really objects strenuously, it doesn't look like the
mail ballot is going to happen. The last time I went through the list
of issues it appeared that the only issues that were ready for release
were:
COMPILE-ENVIRONMENT-CONSISTENCY
COMPILER-LET-CONFUSION
LOAD-TIME-EVAL
SHARP-COMMA-CONFUSION
All the rest are still under discussion or waiting for somebody who
had promised to do something on them. Since it takes about a month to
do a mail ballot under normal circumstances, and with the holiday
season fast approaching to complicate things, I had thought that
December 1 would be the deadline for having things ready to mail out
in order to get the results before the January meeting.
To me, a mail ballot seems like more hassle than it's worth when we
have only these few issues ready to go on it. If somebody else wants
to volunteer to spend the time to get the mailings out and keep track
of the votes, that would be fine with me, but I'd rather spend my time
trying to get more of the pending issues in shape to be voted on at
the January meeting (which means getting them distributed by the first
of the year).
-Sandra
-------
------- End undelivered message -------
∂28-Nov-88 1137 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1137 CL-Compiler-mailer Objects in quoted constants
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:36:51 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA15044@EDDIE.MIT.EDU>; Mon, 28 Nov 88 14:35:30 EST
Received: by spt.entity.com (smail2.5); 28 Nov 88 14:30:36 EST (Mon)
To: RWK@ai.ai.mit.edu
Cc: jonl@lucid.com, cperdue@sun.com, cl-compiler@sail.stanford.edu
In-Reply-To: Robert W. Kerns's message of Sun, 27 Nov 88 03:39 EST <19881127083914.0.RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: Objects in quoted constants
Message-Id: <8811281430.AA08819@spt.entity.com>
Date: 28 Nov 88 14:30:36 EST (Mon)
From: gz@spt.entity.com (Gail Zacharias)
If we allow arrays to lose fill pointers and displacements, i.e. if these are
"attributes which are not preserved" by dumping/loading, do we also have to
allow these to appear where there were none before? Imagine a file compiler
which turns all string constants into complex arrays displaced to one big
simple string. Should that be valid implementation technique? It would make
the following type of code illegal:
(dotimes (i 10) (frobulate (schar "0123456789" i)))
I could be convinced that it's a mistake to have SIMPLE-ARRAY (the type) in
the language, but given that it's there, I don't like the idea of making
unpredictable a fairly large number of perfectly valid language construct such
as (simple-vector-p x) etc. It's not the same as just affecting EQ/EQL, since
people in general understand that loading files involves consing up new copies
of data structures, but I pity the poor teacher who has to explain why loading
a file can change the result of a TYPECASE or invalidate a declaration. In
fact, if there are implementations which simply cannot dump non-simple arrays,
I would prefer to accomodate them by making it illegal (in portable CL) to
have non-simple array constants in compiled files rather than by allowing
the type to change.
On another issue: I disagree that there needs to be a protocol for
dumping/loading structures. I think that now that CLOS is in the language,
structures should only be used for doing simple things simply. If you
really need a complex initialization protocol you should use defclass and
not defstruct. But if you just want a container with some slots, you
shouldn't be forced to write loader functions just because you chose to
make it a structure instead of a vector.
------- End undelivered message -------
∂28-Nov-88 1149 Mailer failed mail returned
To: CL-Object-Oriented-Programming-mailer
The following message was undeliverable to recipient(s):
hthompson%eusip@CS.UCL.AC.UK
Here is how the remote host replied to this mail address:
hthompson%eusip@CS.UCL.AC.UK
550 (NAUTH) Bad authorization for address "hthompson <@CS.UCL.AC.UK:hthompson@eusip>": Sender 'cl-object-oriented-programming-mailer@sail.stanford.edu' not authorized. Mail authorisation@UK.AC.UCL.CS (with an empty message) for help.
------- Begin undelivered message: -------
28-Nov-88 0832 CL-Object-Oriented-Programming-mailer Standard-objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
------- End undelivered message -------
∂28-Nov-88 1150 Mailer failed mail returned
To: CL-Object-Oriented-Programming-mailer
The following message was undeliverable to recipient(s):
ajcole%aivax.ai.leeds.ac.uk@CS.UCL.AC.UK
Here is how the remote host replied to this mail address:
ajcole%aivax.ai.leeds.ac.uk@CS.UCL.AC.UK
550 (NAUTH) Bad authorization for address "ajcole <@CS.UCL.AC.UK:ajcole@aivax.ai.leeds.ac.uk>": Sender 'cl-object-oriented-programming-mailer@sail.stanford.edu' not authorized. Mail authorisation@UK.AC.UCL.CS (with an empty message) for help.
------- Begin undelivered message: -------
28-Nov-88 0832 CL-Object-Oriented-Programming-mailer Standard-objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
------- End undelivered message -------
∂28-Nov-88 1150 Mailer failed mail returned
To: CL-Object-Oriented-Programming-mailer
The following message was undeliverable to recipient(s):
HWB1%CAM.PHX%CAM.ENG-ICF@CS.UCL.AC.UK
Here is how the remote host replied to this mail address:
HWB1%CAM.PHX%CAM.ENG-ICF@CS.UCL.AC.UK
550 (BHST) Unknown host/domain name in "HWB1 <@CS.UCL.AC.UK,@CAM.ENG-ICF:HWB1@CAM.PHX>"
------- Begin undelivered message: -------
28-Nov-88 0832 CL-Object-Oriented-Programming-mailer Standard-objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
------- End undelivered message -------
∂28-Nov-88 1141 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1141 CL-Cleanup-mailer Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:40:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:23:49 PST
Date: 26 Nov 88 20:10 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881128-102349-1309@Xerox>
<<Kent asks that we defer the PATHNAME issues beyond the letter ballot. I
think that is OK, and I am not planning to get more than those issues that
were pending prior to the October meeting ready for the letter ballot; I
expect we will have some more to present and discuss in the January
meeting, however.>>
I think that the clarification could be more constructive than
EXPLICITLY-VAGUE and yet also remain vague.
First, I believe the "partial specification" argument that it might be
useful and valuable for pathnames to have no explicit namestring, because
the pathname is being used for holding data that will be subsequently
merged. Thus, I would prefer to require that MERGE-PATHNAME, MAKE-PATHNAME
etc. not signal errors if given arguments of the correct type.
Secondly, we can say that NAMESTRING may signal an error even if given a
pathname, if no such namestring could be constructed (and the error type);
in addition, OPEN and other functions that take a pathname might also
signal a (different) error if no such file existed.
This would put the burden of consistency checking on NAMESTRING and its
internal equivalent; if such consistency checking is necessary at all, it
would be necessary in NAMESTRING. It also would separate out the error
types.
I have no opinion about what the error types should be, as long as they are
more well specified than "ERROR".
------- End undelivered message -------
∂28-Nov-88 1141 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1141 CL-Cleanup-mailer Issue: SETF-FUNCTION-VS-MACRO
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:41:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:24:45 PST
Date: 26 Nov 88 22:34 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO
To: cl-cleanup@sail.stanford.edu
Message-ID: <881128-102445-1325@Xerox>
I'm working on preparing a single issue with two proposals; I'm making some
progress on simplifying the writeup.
I hope to be done by late Monday.
------- End undelivered message -------
∂28-Nov-88 1141 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1141 CL-Cleanup-mailer Re: Issue: PRINT-CIRCLE-STRUCTURE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:41:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:24:10 PST
Date: 26 Nov 88 20:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PRINT-CIRCLE-STRUCTURE
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Thu, 13 Oct 88
13:43:44 PDT
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881128-102410-1316@Xerox>
Can you submit a new issue on the question of whether *print-circle*
requires detecting of shared structure. I am uncertain about how I would
vote myself, since all of the options have negatives.
------- End undelivered message -------
∂28-Nov-88 1141 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1141 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:41:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:23:59 PST
Date: 26 Nov 88 20:21 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-WILD (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 6 Oct 88 21:50 EDT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881128-102359-1313@Xerox>
I've always presumed that DIRECTORY was nearly idempotent, e.g.,
(let ((x (directory y)))
(assert (or (null x) (equal (directory (car x)) (list (car x))))))
The example is not quite as compelling if it is always safe to call
DIRECTORY on something that might be a pattern....
I don't think we can accept this and also PATHNAME-CANONICAL-CASE; why not
PATHNAME-CANONICAL-WILD and just declare that "*" is the Common Lisp
pathname wild-card character?
------- End undelivered message -------
∂28-Nov-88 1141 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1141 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:41:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:24:29 PST
Date: 26 Nov 88 21:46 PST
From: masinter.pa@Xerox.COM
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 5)
To: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881128-102429-1323@Xerox>
said CLOSE returns T, pointed out that REQUIRE and PROVIDE
might go away.
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Related issues: REQUIRE-PATHNAME-DEFAULTS
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
26-Nov-88, Version 5 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- T
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies; the choices made here are consistent with many but
not all implementations.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. Another proposal would
eliminate them from the language, and then their return value would definitely
be moot!
There is some sentiment for leaving unspecified the values of the
debugging/environment features such as TRACE and UNTRACE,
for the same reasons that so much else of their behavior is unspecified.
------- End undelivered message -------
∂28-Nov-88 1142 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1142 CL-Cleanup-mailer Issue: SETF-FUNCTION-VS-MACRO (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 11:41:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:27:07 PST
Date: 27 Nov 88 15:00 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 5)
To: CL-CLEANUP@Sail.Stanford.EDU
line-fold: NO
cc: masinter.pa@Xerox.COM
Message-ID: <881128-102707-1360@Xerox>
This is an attempt to merge version 3 (from David Moon) and Version 4 (from JonL White, distributed as SETF-PLACES version 1), into a single Issue with two Proposals.
Doing so has not been easy. I must admit that, having gotten a first draft, I'm eager to
mail this out for comments even without having proofread it myself carefully. I'll
do so this week, but if you have some objection to the overall merger, please speak up.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
X3J13 88-002R:
Accessing Slots, Ch. 1 p.11
DEFGENERIC Ch. 2 pp.26-9
DEFMETHOD Ch. 2 pp.39-41
(SETF DOCUMENTATION) Ch. 2 pp.43-5
ENSURE-GENERIC-FUNCTION Ch. 2 pp.46-7
GENERIC-FLET Ch. 2 p.52
GENERIC-LABELS Ch. 2 p.55-6
WITH-ADDED-METHODS Ch. 2 pp.90-1
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
Version 4, 15-Nov-88 JonL, complete rewrite
Version 5, 26-Nov-88 Masinter, merge Versions 3 & 4.
PROBLEM DESCRIPTION:
The SETF mechanism in Common Lisp was designed to allow for a
uniform way of refering to the "update" function of an accessor without
having to have separate names for the updator. The SETF macro shields the user
from ever having to know such names; the correlation between an accessor
name and its corresponding updator name, or updating code sequence, was
established by DEFSETF and DEFINE-SETF-METHOD. Update function names
like SET and RPLACA were retained primarily for backward compatibility.
However, in CLOS programming, generic updator functions must
be specified in pieces, by incremental uses of DEFMETHOD. For this,
and a variety of other reasons, the CLOS specification 88-002R
(accepted by X3J13) assumed that lists of the form (SETF <name>) were
acceptable to a wide variety of functions and macros as a way to
specify the "name" of the SETF function. The problem is that this
part of CLOS must be resolved with the rest of Common Lisp.
This issue has two proposals, NAMED-BY-LIST and COMPUTE-UNDERLYING-NAME.
The proposals differ only in how setf functions are named; the common part
is given first.
PROPOSAL (SETF-FUNCTION-VS-MACRO:COMMON-PART):
Add the concept of a "SETF function". Right now, Common Lisp has two
ways to define the behavior of SETF of a form, DEFINE-SETF-METHOD and
DEFSETF. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
Extend the set of valid "place specifiers" as defined on CLtL p 94-97
by adding a clause after the existing ones, to the effect that:
"For any other place specifier, the form
(SETF (-name- a1 a2 ... an) new-value),
will expand into a call to -name-'s corresponding setf-function,
such expansion to be of the form:
(<setf-function-for--name-> y a1 a2 ... an), except that
the left-to-right evalution order of a1 a2 ... an y is preserved."
A setf function receives the new value to be stored as its first
argument. The setf function for -name- should have one more required
parameter than -name-, the first required parameter is the new value
to be stored, and the remaining paramters should be the same as -name-'s
parameters. A setf function should return its first argument, since
SETF is defined to return the new value.
Note that SETF will no longer signal any "unknown place specifier"
errors during macroexpansion, because the default behavior is to
simply construct a call to the setf function [except, however, when
"access-fn" isn't legal as the name of a function; for example,
(SETF ((SPAZ) I1 I2) VALUE) is still syntaticly illegal]. But if
at run time, the "setf function" still hasn't been defined as a
function [such as by DEFUN, DEFMETHOD, setf of SYMBOL-FUNCTION etc.],
then a run-time "undefined function" error may occur.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function can be retrieved by (documentation '(setf foo) 'function).
The two proposals differ in the manner in which the "name" of
a setf function is determined.
The proposal COMPUTE-UNDERLYING-NAME allows these to be
implementation-dependent, and adds two functions,
UNDERLYING-NAME and UNDERLYING-NAME-TO-SPEC, for converting
from specifications of the form (SETF -name-) to the real
name and back.
The proposal NAMED-BY-LIST specifies that the name of
the setf function for -name- *is* the list (SETF -name-),
and extends those places in Common Lisp that deal with
function names to require them to accept such lists.
PROPOSAL (SETF-FUNCTION-VS-MACRO:COMPUTE-UNDERLYING-NAME):
The name of the setf function for -name- is implementation
dependent; in some implementations, it could be a list (as
with the NAMED-BY-LIST proposal below), but in other
implementations, it could be a symbol.
- Add a new function, UNDERLYING-NAME of one argument:
(i) on any list like (SETF <name>), it returns a unique,
implementation-dependent name suitable for actual use as
a function name in that implementaion.
(ii) on symbols, it is the identity function; and
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
- Add a new function, UNDERLYING-NAME-TO-SPEC of one argument:
(i) on any argument which results from UNDERLYING-NAME applied
to a list (SETF <name>), UNDERLYING-NAME-TO-SPEC returns
an EQUAL list.
(ii) on any symbol or list not covered by part (i),
UNDERLYING-NAME-TO-SPEC returns it's argument.
(iii) on any other data, it is undefined.
The result of UNDERLYING-NAME should be constant across "incarnations"
of the same release of an implementation, and should be of a data type
that can be printed out and read back in reliably.
Thus in one implementation, which uses only symbols to name functions,
it might be that:
(UNDERLYING-NAME '(SETF FOO)) ==> SETF:4.USER.FOO
(UNDERLYING-NAME-TO-SPEC 'SETF:4.USER.FOO) ==> (SETF FOO)
whereas in another implementation, which has LispMachine style
"function specs", it would be that:
(UNDERLYING-NAME '(SETF FOO)) ==> (SETF FOO)
(UNDERLYING-NAME-TO-SPEC '(SETF FOO)) ==> (SETF FOO)
-- Modify the wording in the standard which describes parts imported
from the CLOS specification so as not to imply that lists are
suitable as function names. In particular,
(a) phrases like "... if <function-specifier> names a function" should
be changed to a phrase like "... if <function-specifier> refers to
a defined function", or possibly even something like
"... if (UNDERLYING-NAME <function-specifier>) names a function"
(b) phrases like "(FBOUNDP <function-specifier>)" should be changed
into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
else other terminology should express the intent of what is to
be said. For example, instead of saying: "When (FBOUNDP <f-s>)
is true ..." one could just as well say "When <f-s> refers to
a defined function ..." The choice of which of these two formats
to use is an editorial one.
(c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
or else other terminology should express the intent of what is to
be said. For example, one might say "... the function referred
to by <f-s>". The choice of which of these two formats to use is
an editorial one.
Note that forms like
(DEFMETHOD (SETF FOO) ...)
will expand similarly to
(DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
except that the implicit block name surrounding the body of the method
will be FOO and not (UNDERLYING-NAME '(SETF FOO)).
The underlying call to ADD-METHOD will see the real function name used
for the updator function. The user-level interface of CLOS can still
present the list format as acceptable; it is only the implementation of
DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
"real" name.
In an implementation note, point out that UNDERLYING-NAME-TO-SPEC
could be used by debuggers to print out something more user-comprehensible
than the internal names that an implementation might use.
PROPOSAL (SETF-FUNCTION-VS-MACRO:NAMED-BY-LIST):
The "name" of the setf function for -name- is a list (SETF -name-),
where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
Modify the following functions, macros, special forms, and declarations:
COMPILE function, DEFUN macro, DISASSEMBLE function, DOCUMENTATION function,
FBOUNDP function, FLET special form, FMAKUNBOUND function, FTYPE declaration,
FUNCTION special form, FUNCTION declaration, INLINE declaration,
NOTINLINE declaration, LABELS special form
to accept such lists in addition to symbols as function names, so that
setf functions can be defined and manipulated.
Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;;If SETF of SUBSEQ were not already built into Common Lisp,
;it could be defined, under NAMED-BY-LIST, as:
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;; while with COMPUTE-UNDERLYING-NAME, as:
(setf (symbol-function (underlying-name '(setf subseq)))
#'(lambda (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value i)))))
;;Another example, showing a locally defined setf function.
;; with NAMED-BY-LIST:
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;; with COMPUTE-UNDERLYING-NAME:
; First, define MIDDLE-REF to be an accessor function as follows:
(defun middle-ref (vec i)
(check-type i fixnum)
(aref vec (ceiling i 2)))
;; then, even given:
(defun #.(underlying-name '(setf middle-ref)) (new-element vec i)
(check-type i fixnum)
(setf (aref vec (ceiling i 2)) new-element))
(flet ((#.(underlying-name '(setf middle-ref)) (new-element vec i)
;;"wide-body" version of set-middle-ref
(declare (ignore i))
(fill vec new-element :end (ceiling i 2))))
(setf (middle-ref "abc" 1) #\z))
;;;GET-SETF-METHOD could implement setf functions by calling
;;;this function when none of the other rules of CLtL p 94-7 apply:
(defun get-setf-method-for-setf-function (form)
(let ((access-fn (car form))
(new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(,@
#+NAMED-BY-LIST
`(funcall #'(setf ,access-fn))
#+COMPUTE-UNDERLYING-NAME
`(,(underlying-name `(setf ,access-fn)))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
Both proposals allow a more functional appropach to dealing with
SETF, and bring the CLOS and Common Lisp parts of the standard into
more alignment. COMPUTE-UNDERLYING-FUNCTION does so by adding functions
to go between the "specification" of (SETF -name-) to the name
actually used, while NAMED-BY-LIST does so by extending a number
of already existing Common Lisp functions, macro and special forms.
SETF functions take the "new value" as the first argument to allow
for defining them on accessors that have &REST and &KEY arguments.
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a feature similar,
but not compatible with, NAMED-BY-LIST, in that they allow setting
functions named (SETF reader). We don't know of any implementation
that has precisely the proposed feature.
For example, This will be an incompatible change for Symbolics,
since it already has setf functions but they do not take the
same arguments as proposed here.
COST TO IMPLEMENTORS:
For either proposal, the SETF macro expansion would have to be
extended to generate the appropriate call on the setf function.
The additional cost of proposal COMPUTE-UNDERLYING-NAME is low;
implementations would need to add the two proposed functions.
In addition, implementations would need to modify their
CLOS implementation to use UNDERLYING-NAME where appropriate.
[A sample implementation is given at the end of the proposal.]
The cost of proposal NAMED-BY-LIST is higher, since many other
functions, macros and special forms would have to be extended to
deal with the SETF specifications. The main cost is generalization
of a few functions to accept lists beginning with SETF where they
now accept only symbols. Implementations must add a data structure
to store the function definition of a setf function, however, this can
be done with property lists or generated symbols.
COST TO USERS:
Both proposals are basically upward-compatible changes for currently
portable Common Lisp programs.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue with NAMED-BY-LIST is programs
that assume that all function names are symbols. They may use GET to
access properties of a function name or use EQ or EQL (perhaps via
MEMBER or ASSOC) to compare function names for equality. Such programs
will need improvement before they can understand programs that use
the new feature.
Both proposals remove some macro-expansion error checking, since
detection of incorrect SETF expansion will be postponed to run-time.
This is a minor deficiency, as it puts invocation of SETF functions
on the same footing as other function calls.
COST OF NON-ADOPTION:
Common Lisp and CLOS would be significantly inconsistent; some major
rethinking of CLOS would be required.
BENEFITS:
Improve usability of SETF. Avoids cost of non-adoption.
With NAMED-BY-LIST, current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
could be replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
With NAMED-BY-LIST, a convenent way of lexically defining
or redefining the behavior of SETF would be allowed.
PERFORMANCE IMPACT:
Negligible; ether proposal might make an implementation slightly
larger.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
The proposal NAMED-BY-LIST allows lists of the form (SETF -name-) to be
used in many places where only symbols were allowed before. Some
people feel this is unesthetic, because it is at odds with many
current descriptions of Common Lisp say that names are symbols.
DISCUSSION:
This issue has been in discussion in the CLOS committee and at X3J13
for over a year. Versions of the proposal were distributed, discussed,
and voting tabled at three successive meetings of X3J13. The proposal
previously distributed most resembles the NAMED-BY-LIST proposl contained
in this version.
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. Neither proposal attempts to
change that aspect of Common Lisp.
Most of the objection to previous proposals were based on
introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
The CLOS group unsuccessfully tried a number of alternatives that
did not require naming the setf function at all. However,
fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
!
Appendix: Sample implementation of COMPUTE-UNDERLYING-NAME
The following code can be used by an implementation which doesn't
have "function specs" to implement the COMPUTE-UNDERLYING-NAME proposal:
;;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: SYSTEM; Base: 10 -*-
;;;
;;; Author: JonL White, 15-Nov-88
;;;
(in-package "SYSTEM") ;or, your development package
(eval-when (eval compile load)
;;; The SETF package should be reserved for this purpose
;;;
(or (find-package "SETF")
(make-package "SETF" :use nil))
(defparameter *setf-package* (find-package "SETF"))
(unless (and (null (package-use-list *setf-package*))
(null (package-used-by-list *setf-package*)))
(error "SETF package has connections?"))
;;; "Internal Markers", to be used for uninterned symbols.
;;;
(export (intern "SETF-SPEC" *setf-package*) *setf-package*)
(export (intern "SETF-NAME" *setf-package*) *setf-package*)
)
(eval-when (eval compile)
(defmacro setf-spec-p (x)
(let ((spec (gensym)))
`(LET ((,spec ,x))
(AND (CONSP ,spec)
(EQ (CAR ,spec) 'SETF)
(CONSP (CDR ,spec))
(NULL (CDDR ,spec))
(SYMBOLP (SECOND ,spec))))))
)
(defun UNDERLYING-NAME (spec)
(cond
((symbolp spec)
spec)
((setf-spec-p spec)
(let* ((accessor (second spec))
(accessor-name (symbol-name accessor))
(home-package (symbol-package accessor)))
(if home-package
(let* ((package-name (package-name home-package))
;; 'spec-name' is a form like "~D.~A.~A", but FORMAT has a
;; problem with global print parameters like *print-radix*
(spec-name (concatenate 'string
(write-to-string (length package-name)
:radix nil :base 10 :length nil :level nil)
"."
package-name
"."
accessor-name))
(updator (or (find-symbol spec-name *setf-package*)
(let ((sym (intern spec-name *setf-package*)))
(export sym *setf-package*)
sym))))
;; A possible optimization, which trades off space for time, is
;; as follows; see definition of UNDERLYING-NAME-TO-SPEC below
;;(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)
(or (get accessor 'setf:setf-name)
(let* ((uname (concatenate 'string "SET-" accessor-name))
(updator (make-symbol uname)))
(setf (get accessor 'setf:setf-name) updator)
(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)))))
(t
(error "~S is an invalid arg for ~S" spec 'UNDERLYING-NAME))))
(defun UNDERLYING-NAME-TO-SPEC (x)
(cond
((not (symbolp x))
(if (setf-spec-p x)
x
(error "~S is an invalid arg for ~S"
x 'UNDERLYING-NAME-TO-SPEC)))
((get x 'setf:setf-spec))
(t
(let ((home-package (symbol-package x)))
(if (not (eq home-package *setf-package*))
x
(let ((name (symbol-name x))
accessor package-name)
;; Unpack the name, which is a form like "~D.~A.~A"
(multiple-value-bind (nchars starti)
(parse-integer name :radix 10 :junk-allowed t)
(incf starti)
(setq package-name (subseq name starti (incf starti nchars)))
(incf starti)
(setq accessor (find-symbol (subseq name starti)
(find-package package-name)))
(unless accessor
(error "~S failed to parse in ~S"
x 'UNDERLYING-NAME-TO-SPEC))
`(SETF ,accessor))))))))
------- End undelivered message -------
∂28-Nov-88 1204 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1204 CL-Compiler-mailer Objects in quoted constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 12:04:34 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00619g; Mon, 28 Nov 88 12:00:02 PST
Received: by bhopal id AA02027g; Mon, 28 Nov 88 11:58:54 PST
Date: Mon, 28 Nov 88 11:58:54 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811281958.AA02027@bhopal>
To: RWK@F.ILA.Dialnet.Symbolics.COM
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu, RWK@ai.ai.mit.edu
In-Reply-To: Robert W. Kerns's message of Sun, 27 Nov 88 03:39 EST <19881127083914.0.RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: Objects in quoted constants
re: . . . You're using the fill-pointer as a convenient place to store
an additional piece of data in your data structure, to avoid having a
real "data structure".
That's true. But since the FILL-POINTER "slot" of an array is defined
sufficiently abstractly, that I don't think preserving it violates your
rule:
5) Convey less information, rather than more, when it leads to a more
abstract view of an object. It is the high-level view of objects
which are preserved by PRINT/READ, and by dump/load.
-- JonL --
------- End undelivered message -------
∂28-Nov-88 1219 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1219 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 12:17:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA15861; Mon, 28 Nov 88 13:15:50 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11493; Mon, 28 Nov 88 13:14:30 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811282014.AA11493@defun.utah.edu>
Date: Mon, 28 Nov 88 13:14:28 MST
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 28 Nov 88 13:00 EST
Actually, I don't see much in this proposal that hasn't already been
addressed by the latest proposal on issue CONSTANT-COMPILABLE-TYPES.
In particular, I think we have reached some consensus that COMPILE
ought to leave constants alone, or at least ought to impose only the
same constraints that QUOTE does in interpreted code (which is a
separate issue). The only implementation I know of that implemented
COMPILE using file compilation (KCL) apparently no longer does so. V3
of the writeup on CONSTANT-COMPILABLE-TYPES says this, although not
very clearly.
There are a number of issues that your proposal leaves ambiguous. For
example, it does not address the issue of whether the compiler/loader
must preserve array attributes such as the element-type, or address
the problems that can arise from coalescing hash table keys. I don't
think this issue can subsume an issue which *does* explicitly deal
with that issue.
It seems to me like the other differences between your proposal and
Cris's (handling of uninterned symbols and readtables, for example)
could be ironed out in the context of the existing issue. I don't
think it's necessary (or even a good idea) to open an entirely new
issue just because you don't like the existing writeup.
-Sandra
-------
------- End undelivered message -------
∂28-Nov-88 1314 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; IIM@ECLA.USC.EDU
------- Begin undelivered message: -------
28-Nov-88 1314 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 13:13:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498670; Mon 28-Nov-88 16:13:51 EST
Date: Mon, 28 Nov 88 16:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8811282014.AA11493@defun.utah.edu>
Message-ID: <881128161350.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 28 Nov 88 13:14:28 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
... it does not address the issue of whether the compiler/loader
must preserve array attributes such as the element-type, or address
the problems that can arise from coalescing hash table keys. ...
First of all, I think CONSTANT-ARRAY-ATTRIBUTES is an ill-motivated issue.
It's problem description asks a question, it does not pose a problem.
Further, it doesn't motivate the question. It might as well say
"Does file compilation of symbols preserve package information, since
often PRINT loses this information?" Foo. Of course it does. File
compilers are responsible for preserving what is reasonably preservable.
There is no stretch of the imagination by which it is not reasonable to
preserve all attributes of an array except maybe displacement (because it
relies on EQL, and because EQL is inherently ill-defined in such a situation).
Anyway, my proposal actually says that compilation preserves EQUAL.
That's much more important than saying explicitly which attributes,
since in fact an implementation (such as ours) may have
implementation-specific attributes which might or might not be
preserved. Since our EQUAL knows which of those attributes matter and
which do not, there's a clear theory of what the compiler/loader must
maintain.
... I don't think this issue can subsume an issue which *does*
explicitly deal with that issue. ...
You suggest there are more such issues, but you didn't list them.
I don't know what the scope of this list is. If adding a few lines to this
proposal can bring us in line with these other proposals, which taken
together are 4 times the amount of reading material, then I think a
switch is worth it.
It seems to me like the other differences between your proposal and
Cris's (handling of uninterned symbols and readtables, for example)
could be ironed out in the context of the existing issue. I don't
think it's necessary (or even a good idea) to open an entirely new
issue just because you don't like the existing writeup.
I don't like Cris's proposal because
- I don't think it presents a clear description of what problem
he is trying to solve.
- The description is caught up in some sort of weird pseudo-formal
mumbo-jumbo which is opaque to me. This issue is a serious one and
a poor presentation is going to mean that people who need to read
it do not read it, and people who should be able to comment on it
will be unable to spend the time necessary to comment adequately.
You may agree or disagree with my proposal, but at least it is intelligible.
People can reasonably look at it and quickly decide if they agree or disagree
with it. I have seen two other reviews on this (one from RWK and one from
Moon) suggesting that Cris get a technical writer to help him. I think he
should really heed that comment, and should take seriously this alternate
presentation and any other suggestions he receives on how to simplify the
presentation, and to clarify its motivation.
------- End undelivered message -------
∂28-Nov-88 1345 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1345 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 13:44:48 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA21086; Mon, 28 Nov 88 14:44:15 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11542; Mon, 28 Nov 88 14:43:59 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811282143.AA11542@defun.utah.edu>
Date: Mon, 28 Nov 88 14:43:58 MST
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 28 Nov 88 16:13 EST
> Date: Mon, 28 Nov 88 16:13 EST
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
>
> Anyway, my proposal actually says that compilation preserves EQUAL.
> That's much more important than saying explicitly which attributes,
> since in fact an implementation (such as ours) may have
> implementation-specific attributes which might or might not be
> preserved. Since our EQUAL knows which of those attributes matter and
> which do not, there's a clear theory of what the compiler/loader must
> maintain.
I'm confused here. CLtL says that two arrays are EQUAL iff they are
EQ, which is of little use in comparing arrays in two different
running Lisps. Your proposal says that if two arrays are EQUAL in the
compiler's environment, then they will also be EQUAL in the loader's
environment, but that will be the case both if array attributes are
preserved and if they aren't. It doesn't tell me if I can count on
the element-type of a constant array being the same in the load time
environment as in the compile time environment.
> I don't like Cris's proposal because [...]
By this time, I think we're all convinced that Cris's proposal needs
to be reworded. What I was objecting to is opening a completely new
issue to deal with an issue that we're already discussing under
a different name.
-Sandra
-------
------- End undelivered message -------
∂28-Nov-88 1351 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1351 CL-Compiler-mailer issue DEFCONSTANT-NOT-WIRED, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 13:51:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA21269; Mon, 28 Nov 88 14:50:33 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11550; Mon, 28 Nov 88 14:50:30 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811282150.AA11550@defun.utah.edu>
Date: Mon, 28 Nov 88 14:50:28 MST
Subject: issue DEFCONSTANT-NOT-WIRED, version 5
To: cl-compiler@sail.stanford.edu
Here is a new version of this issue. I have cleaned up the "problem
description" section some and tried to clarify the wording here and
there, but the content is mostly unchanged. I hope this will be the
last iteration on this issue (David and I seem to have stopped arguing
about it, at least).
-Sandra
Issue: DEFCONSTANT-NOT-WIRED
References: CLtL pages 68-69
Related issues: DEFCONSTANT-VALUE,
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS,
PROCLAIM-LEXICAL,
DECLARE-TYPE-FREE,
DEFCONSTANT-SPECIAL
Category: ADDITION
Edit history: 9 Oct 1988, V1 by David Gray
27 Oct 1988, V2 by David Gray (new proposal)
10 Nov 1988, V3 by David Gray - updated proposal, rationale
and discussion sections in response to comments.
21 Nov 1988, V4 by David Gray - SPECIAL cancels CONSTANT;
CONSTANT doesn't require previous SPECIAL.
28 Nov 1988, V5 by Sandra Loosemore (clean up, fix
some consistency problems)
Problem description:
In some cases, one would like to have the functionality of declaring
a symbolic constant where run-time alteration of the value is
prohibited (like DEFCONSTANT), but where the value is should be computed
at load time and not be "wired in" by the compiler (like DEFPARAMETER).
Although DEFPARAMETER can be used for this purpose, one loses the
benefits of the behavior in many implementations where an error or
warning is signalled when an attempt is made to modify a variable
declared with DEFCONSTANT. It would be inappropriate for DEFPARAMETER
to signal a warning or error, since CLtL explicitly allows modification
of the value.
Proposal DEFCONSTANT-NOT-WIRED:NEW-DECLARATION
Add a new declaration to the language:
(CONSTANT {varname}+)
This can be used in either a PROCLAIM to refer to global variables or
in a DECLARE to refer to lexical variables. It specifies that the
variables named are to be treated as constants after their initial
value is established.
For global variables, (PROCLAIM '(CONSTANT varname)) provides a subset
of the behavior of DEFCONSTANT:
* A free reference to a variable proclaimed to be CONSTANT always
refers to its global value.
* It is an error if there are any special bindings of the variable at
the time the PROCLAIM form is executed (but implementations may or
may not check for this.)
* Once a name has been declared by (PROCLAIM '(CONSTANT ...)) to
be constant, any further assignment to or binding of that special
variable is an error. (Errors may be reported during compilation
rather than during execution of compiled code.)
* A compiler may also choose to issue warnings about bindings of the
lexical variable of the same name.
[Editorial note: the above points are intended to be consistent
with DEFCONSTANT so the wording should be updated accordingly.]
However, proclaiming a variable CONSTANT does -not- authorize the
compiler to "wire in" its value.
For lexical variables, (DECLARE (CONSTANT ...)) means that the
variable is not permitted as the destination of a SETQ. (Knowing in
advance that the value won't be altered by a SETQ makes it easier for
compilers to perform certain optimizations.) Implementations are not
required to signal an error if they don't depend on this information.
Whether the declaration must accompany a binding or can be used free
shall be consistent with the rules for type declarations determined by
the outcome of issue DECLARE-TYPE-FREE.
Examples:
(SETQ MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
(PROCLAIM '(CONSTANT MEMORY-SIZE))
computes at load-time the value of MEMORY-SIZE, which can then be
used in subsequent initialization to control the allocation of data
structures for an application. Once these structures are created,
changing this parameter would make no sense and might even break the
program. A DEFCONSTANT is not appropriate because the value needs to
be computed at load time, and because the value must not be wired in to
any files compiled later or else those object files could not be used
on another machine with a different memory size.
(LET ((SHORT-PI (COERCE PI 'SHORT-FLOAT)))
(DECLARE (CONSTANT SHORT-PI))
...)
Here the declaration assists a human reader of the program in
recognizing how SHORT-PI is being used, and encourages the compiler to
substitute the value where it is used. (This optimization could be
done without the declaration, but is complicated by the possibility of
alteration within loops or closures.)
Rationale:
This proposal makes one of the hooks used by DEFCONSTANT available
to user code.
Providing a new declaration seems to be a cleaner and more flexible
approach than adding an additional defining macro, and has additional
usefulness with lexical variables.
For the purposes that motivated this proposal, it would be simpler to
just support (PROCLAIM '(CONSTANT ...)), but allowing local CONSTANT
declarations seems like such a natural extension that it would seem an
artificial restriction to not permit it.
Local CONSTANT declarations are not permitted for special variables
because there is more than one interpretation of what that should
mean, and it doesn't seem very useful anyway.
The error signalling behavior has been specified in such a way as to
minimize the cost to implementors and to avoid slowing down
interpreters with additional bookkeeping.
Current practice:
No implementation of this proposal is known.
The Explorer has a capability equivalent to (PROCLAIM '(CONSTANT ...))
which is used internally for various system parameters, since changing
them could crash the system, but the value should not be wired in to
object files in order to maintain object compatibility between
software releases.
Cost to Implementors:
The minimum requirements are to permit the CONSTANT declaration
(trivial), and to prevent alteration of variables that have been
PROCLAIMed constant, which should be easy since the mechanism
should already exist for DEFCONSTANTs.
More work would be needed for a compiler to record lexical constant
declarations and report errors for violations. This is not trivial,
but not difficult either.
Cost to Users:
One more little feature to learn. Some user code may need to be
modified as a result of the addition of the symbol CONSTANT to the
LISP package.
Cost of non-adoption:
Continued confusion from the desire to use DEFCONSTANT for situations
that it isn't quite right for, or from expecting DEFPARAMETER to do
more than it does.
Performance impact:
Could help run-time speed by making it easier for compilers to support
value propagation for lexical variables.
Benefits:
Provides a more complete set of options to the user.
Esthetics:
Complicates the language by adding one more declaration, but having
this as a separate feature facilitates giving a clear and simple
definition to DEFCONSTANT and avoids a battle over what DEFPARAMETER
means.
This seems like an elegant solution -- simple syntax with an obvious
meaning.
Discussion:
Version 1 of this issue proposed adding a new macro called
DEFPARAMETER-UNALTERABLE, but no one seemed to like it. (It would
have been equivalent to DEFPARAMETER followed by PROCLAIM CONSTANT.)
It may be desirable to have stricter requirements for signalling
errors if this idea is popular enough for implementors to accept the
cost.
If proposal PROCLAIM-LEXICAL is adopted, this proposal might need to
have some of the details adjusted, but let's not worry about that yet.
Note that (DEFCONSTANT name value) is equivalent to something like:
(EVAL-WHEN (EVAL COMPILE LOAD)
(SETQ name value)
(PROCLAIM '(CONSTANT name))
(<enable-value-substitution> 'name) ; this part is not standardized
'name)
(Some additional magic must be added to allow DEFCONSTANTs to be
redefined.)
It has been suggested that a declaration called CONSTANT would appear to
imply being fully equivalent to DEFCONSTANT, so that a different name
for this declaration might be less confusing. It could be called
something like INVARIANT instead. In the absence of an obviously ideal
name, let's just vote on what name we like best at the next meeting.
-------
------- End undelivered message -------
∂28-Nov-88 1420 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1420 CL-Cleanup-mailer EOF during READ-DELIMITED-LIST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 14:20:34 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 28 Nov 88 17:17:38 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 28 Nov 88 17:17:48 EST
Date: Mon, 28 Nov 88 17:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: EOF during READ-DELIMITED-LIST
To: cl-cleanup@sail.stanford.edu
Message-Id: <19881128221756.3.BARMAR@OCCAM.THINK.COM>
According to CLtL p.378, "it is always an error to hit end-of-file
during the operation of READ-DELIMITED-LIST." This makes
READ-DELIMITED-LIST almost useless, because it means that some user
input to an application can cause undefined effects.
I think that this particular "is an error" was not intended this way.
READ-DELIMITED-LIST should be the function that the standard "(" macro
character uses, and the latter is defined to signal an error if an EOF
occurs before the matching delimiter is read. Also, the previous
sentence says that this is the reason that there is no EOF-ERROR-P
argument; the implication is that READ-DELIMITED-LIST has an implicit
EOF-ERROR-P argument that is always non-NIL.
Has this already been cleaned up?
barmar
------- End undelivered message -------
∂28-Nov-88 1427 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1427 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 14:27:37 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498730; Mon 28-Nov-88 17:21:27 EST
Date: Mon, 28 Nov 88 17:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8811282143.AA11542@defun.utah.edu>
Message-ID: <881128172122.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 28 Nov 88 14:43:58 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Mon, 28 Nov 88 16:13 EST
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
>
> ... Since our EQUAL knows which of those attributes matter and
> which do not, there's a clear theory of what the compiler/loader must
> maintain.
I'm confused here. CLtL says that two arrays are EQUAL iff they are
EQ, ...
Oops. No, I was suffering from a brain lapse there. This obviously says
we need a new function here since neither EQUAL nor EQUALP will suffice.
(EQUAL couldn't really have sufficed anyway because of circularity.)
Actually, two predicates are really needed (or one with two return values):
- One to say if the object is valid for comparison with this predicate.
- The other, a two-place equality predicate defined only on certain types.
In any case, I seriously believe we should write these functions in CL.
I think that will simplify the presentation a lot and get rid of all this
"level 0" and "level N" stuff which is so confusing in Cris's current
writeup.
It may or may not be interesting to name these functions.
------- End undelivered message -------
∂28-Nov-88 1515 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1515 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 15:15:43 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
id AA01845; Mon, 28 Nov 88 15:12:16 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA10098; Mon, 28 Nov 88 15:15:03 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA09856; Mon, 28 Nov 88 15:15:58 PST
Date: Mon, 28 Nov 88 15:15:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811282315.AA09856@clam.sun.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu
Subject: Re: Issue: FILE-COMPILATION (Version 1)
Cc: CL-Compiler@SAIL.Stanford.EDU
> Oops. No, I was suffering from a brain lapse there. This obviously says
> we need a new function here since neither EQUAL nor EQUALP will suffice.
> (EQUAL couldn't really have sufficed anyway because of circularity.)
>
Yes, yes! Kent's FILE-COMPILATION proposal is the one I feel most
urgently needs a reply, but already this latest note from him begins
to deal with the key issues, which is excellent. EQUALity is not
a property of an object, and in general it neither compares "circular"
constants nor ones in different address spaces.
> Actually, two predicates are really needed (or one with two return values):
> - One to say if the object is valid for comparison with this predicate.
My existing proposal is not trying to define this first predicate. It seems
to me that it might be a good idea and then again it might not. For
one thing there are at least two ways to define this: it can test
whether all valid CL implementations must successfully compile the
object as a quoted constant; or it could test whether the
implementation actually running will successfully compile the given
object as a quoted constant. I don't see the actual *necessity* of
such a predicate in any case. See also more discussion below.
> - The other, a two-place equality predicate defined only on certain types.
>
You might call this predicate "similar-as-constants", exactly as in
CONSTANT-COMPILABLE-TYPES:SPECIFY. The name "congruent" occurs to me
also, and the notion of "same shape" implied by "congruent"
seems quite appropriate.
> In any case, I seriously believe we should write these functions in CL.
> I think that will simplify the presentation a lot and get rid of all this
> "level 0" and "level N" stuff which is so confusing in Cris's current
> writeup.
>
The "level 0" and "level N" stuff is there to avoid having to give a
specific algorithm for coping with "circular" structures. If two constants
are similar at all levels then they are similar, and this definition
I claim handles the case of "circular" constants implicitly.
The idea of writing down one specific algorithm for handling
circularity seems an unattractive way to specify the idea.
The other objection to "writing it in Common Lisp" that comes to mind
immediately is that there are properly various cases that "are errors"
and the predicate in effect doesn't give any particular answer when
given such an "improper" constant.
Alternatively, we could consider the implementation-specific version
of the predicate, one that tells whether a constant is compilable in
this particular implementation. I suspect that even here the answer
might not always be just T or NIL. It might be something like, "Yes,
you can compile this open stream, but when you load it, we attempt to
open the file with the same truename, and position it to the same place.
This may not always give the effect that you wanted, and it may result
in a loadtime error."
Overall, I personally think that there are *big* holes in CLtL in
the area of compilation and that treatment of constants is one of them.
Part of the reason people are having trouble reading my proposal and
I am having trouble writing it is that properly specifying this
aspect of Common Lisp is new territory. I hope that the on-line
discussions will help active people in the committee and it will show
me how to better motivate and clearly present the proposal.
------- End undelivered message -------
∂28-Nov-88 1543 Mailer failed mail returned
To: CL-Characters-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1543 CL-Characters-mailer extended character sets in symbols
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 15:41:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 15:35:01 PST
Date: 28 Nov 88 15:33 PST
From: masinter.pa@Xerox.COM
Subject: extended character sets in symbols
To: cl-characters@sail.stanford.edu
cc: Fischer.aisnorth@Xerox.COM
Message-ID: <881128-153501-3504@Xerox>
I had assumed that the proposal on character handling in strings would
retain the requirement that all strings were admissible arguments to
INTERN, and that
(string-equal (symbol-name (intern string)) string)
for all valid strings.
This would mean that extended characters, if supported by an
implementation, would also be allowable in symbol names.
I've heard from some people who have read the "DRAFT: Extensions to Common
LISP to Support ...." who weren't sure that was an implication of the
proposal.
I'd like to make sure it is explicit.
Did any of you intend otherwise?
------- End undelivered message -------
∂28-Nov-88 1543 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1543 CL-Cleanup-mailer Re: dispatch macro characters
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 15:41:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 NOV 88 14:52:29 PST
Date: 28 Nov 88 14:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: dispatch macro characters
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Mon, 28 Nov 88
14:15 EST
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881128-145229-3361@Xerox>
as far as I know, there have been no cleanup items submitted about
dispatching macro characters.
As for "What does GET-MACRO-CHARACTER return if the character is a
dispatching character"
In Envos Medley, it returns a function (actually a lambda expression)
In Procyon Common Lisp, it returns PROCYON::DISPATCH-MACRO-MACRO
So I'd say the cleanup proposal should propose answers to your questions
as:
1) implementation-defined
2) no
3) no-op
------- End undelivered message -------
∂28-Nov-88 1543 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1543 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 15:41:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 15:10:55 PST
Date: 28 Nov 88 15:10 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
In-reply-to: your message of Mon, 28 Nov 88 14:22:10 EST
To: cl-cleanup@sail.stanford.edu
cc: Joe Boykin <boykin@encore.com>
Message-ID: <881128-151055-3416@Xerox>
In a previous message on this issue, I said that there isn't an ANSI
standard for Unix. I have been corrected, viz:
"FYI: There is an ANSI standard for UNIX, it was developed by the POSIX
P1003.1 group under the sponsorship of the IEEE Computer Societies
Technical Committee on Operating Systems. The standard was a "trial
use" standard for approximately two years and was recently (Aug 22,
1988) approved as a full IEEE/ANSI standard. Draft 12 of P1103.1 has
also been an interim FIPS (Federal Information Processing Standard) for
approximately a year.
Among other things, POSIX includes a definition of a pathname."
This would mean that we could in fact define in the ANSI Standard for
Common Lisp how the pathname functions should work when operating on files
stored within IEEE/ANSI Standard Unix.
I think this would be a Good Idea. I don't think it needs to be done in
time for the next meeting. I'm not sure that it has to form part of the
Draft Standard for Common Lisp, at this point, since often documents that
interrelate two standards are external to both of them.
------- End undelivered message -------
∂28-Nov-88 1744 Mailer failed mail returned
To: CL-Characters-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1744 CL-Characters-mailer extended characters in symbols
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:44:07 PST
Date: Mon, 28 Nov 88 16:26:44 PST
From: Thom Linden <baggins@ibm.com>
To: Larry Masinter <masinter.pa@xerox.com>
cc: cl-characters@sail.stanford.edu, Fischer.aisnorth@Xerox.COM
Message-ID: <881128.162644.baggins@IBM.com>
Subject: extended characters in symbols
>> I had assumed that the proposal on character handling in strings would
>> retain the requirement that all strings were admissible arguments to
>> INTERN, and that
>>
>> (string-equal (symbol-name (intern string)) string)
>>
>> for all valid strings.
>>
>> This would mean that extended characters, if supported by an
>> implementation, would also be allowable in symbol names.
>>
>> I've heard from some people who have read the "DRAFT: Extensions to Common
>> LISP to Support ...." who weren't sure that was an implication of the
>> proposal.
>>
>> I'd like to make sure it is explicit.
>>
>> Did any of you intend otherwise?
>>
That is the intention. We'll add your example since someone felt
this was in question.
Regards,
Thom
------- End undelivered message -------
∂28-Nov-88 1803 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 18:02:56 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA22029; Mon, 28 Nov 88 18:00:13 PST
Date: Mon, 28 Nov 88 18:00:13 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811290200.AA22029@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA22015; Mon, 28 Nov 88 18:00:13 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA09801; Mon, 28 Nov 88 18:01:27 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST
Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: common-lisp@sail.stanford.edu
Message-Id: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
If you look at most implementations, and at the examples on pg 351, then
you'd think it should be `(a . b)
However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
I tried Ibuki, Franz, Lucid, and Genera.
In all of them evaluating '`(,@'(a . b)) => `(a . b).
In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil)
while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b)
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
∂28-Nov-88 1745 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; rms@prefect.es.llnl.gov
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
28-Nov-88 1745 Common-Lisp-mailer inconsistency in backquote spec?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST
Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: common-lisp@sail.stanford.edu
Message-ID: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
If you look at most implementations, and at the examples on pg 351, then
you'd think it should be `(a . b)
However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
I tried Ibuki, Franz, Lucid, and Genera.
In all of them evaluating '`(,@'(a . b)) => `(a . b).
In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil)
while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b)
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
------- End undelivered message -------
∂28-Nov-88 1855 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1855 CL-Compiler-mailer Objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 18:55:07 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 18:47:55 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296922; 28 Nov 88 21:51:53 EST
Date: Mon, 28 Nov 88 21:21 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Objects in quoted constants
To: Jon L White <jonl@lucid.com>, RWK@f.ila.dialnet.symbolics.com
Cc: cperdue@sun.com, cl-compiler@sail.stanford.edu
In-Reply-To: <8811281958.AA02027@bhopal>
Message-Id: <19881129022116.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Mon, 28 Nov 88 11:58:54 PST
From: Jon L White <jonl@lucid.com>
re: . . . You're using the fill-pointer as a convenient place to store
an additional piece of data in your data structure, to avoid having a
real "data structure".
That's true. But since the FILL-POINTER "slot" of an array is defined
sufficiently abstractly, that I don't think preserving it violates your
rule:
5) Convey less information, rather than more, when it leads to a more
abstract view of an object. It is the high-level view of objects
which are preserved by PRINT/READ, and by dump/load.
I do, so maybe I didn't state my rule well enough!
I've probably said enough on this, though, so I'll just observe that
PRINT/READ definitely do NOT preserve the EXISTENCE of the fill pointer.
------- End undelivered message -------
∂28-Nov-88 1856 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1856 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 18:56:22 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 18:49:08 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296925; 28 Nov 88 21:54:31 EST
Date: Mon, 28 Nov 88 21:34 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Cc: Cris Perdue <cperdue@sun.com>, cl-compiler@sail.stanford.edu,
beckerle%clam@sun.com, moon%clam@sun.com, vanroggen%clam@sun.com,
gz%clam@sun.com, jmiller%clam@sun.com
In-Reply-To: <8811281841.AA11420@defun.utah.edu>
Message-Id: <19881129023407.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Mon, 28 Nov 88 11:41:00 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Sun, 27 Nov 88 03:50 EST
> From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
>
> ....note that there is
> NO REQUIREMENT that the coalescence equivalence predicate, and the one
> which defines what properties are preserved, be the same predicate!
I agree with this, however it is convenient for them to be the same.
Convenience, like Store 24 where you can pay more day or night?
> As this proposal is written, logic dictates EQL as
> the coalescence predicate.
You'll have to spell out your argument in more detail. Maybe it's just
because it's Monday :-(, but it's not at all obvious to me.
Because of hash tables, and the other coalescence screws! Actually, EQL
isn't right, either, because EQ hash tables exist. EQ is the right one.
The key phrase here is "as this proposal is written". I am, in fact, in
favor of EQ as the coalescence predicate, because of the simpler
semantics, but I'll accept anything done in a self-consistent manner, up
to something in the vicinity of EQUAL.
Trying to be slightly formal with this again, the proposal defines a
relation between the set of constants in the compiler's environment and
a set of constants in the loader's environment. The relationship
guarantees that any constants that are equivalent in the compiler's
environment will also be equivalent in the loader's environment.
What the proposal does not address is whether the same constant in the
compiler's environment must always map into the same constant in the
loader's environment (i.e., preservation of shared structure), and
vice versa (coalescing of constants). The most general situation is
if we specify that the coalescence predicate should be the same as the
relationship that defines the equivalence classes. Specifying it to
be EQL would essentially force the relationship to be monotonic --
each object in the loader's environment must correspond to exactly one
object in the compiler's environment.
I'd argue for generalizing because it makes more sense to use the
compile/load equivalence relationship instead of EQUAL as the coalescing
predicate, and current practice is on the side of allowing coalescing
rather than disallowing it.
I agree with everything you say here except for the choice of which
predicate to adopt. I think current practice is predicated (no pun
intended) on a false assumption: that it improves the "performance" of
the program (either the size of the files, or of the loaded files, or
whatever) in some significant way. I don't believe that anymore, and I
now favor EQ or EQL as the coalescing predicate. My reasons are
primarily based on simplicity and consistency. I think we agree
completely on everything else.
If everyone else wants to codify existing practice, instead, I'll
certainly help that, except I won't be around to debate it over the next
month or so.
------- End undelivered message -------
∂28-Nov-88 1857 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 1857 CL-Compiler-mailer Objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 18:56:23 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 18:49:14 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296924; 28 Nov 88 21:53:45 EST
Date: Mon, 28 Nov 88 21:19 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Objects in quoted constants
To: Gail Zacharias <gz@spt.entity.com>, RWK@ai.ai.mit.edu
Cc: jonl@lucid.com, cperdue@sun.com, cl-compiler@sail.stanford.edu
In-Reply-To: <8811281430.AA08819@spt.entity.com>
Message-Id: <19881129021913.6.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: 28 Nov 88 14:30:36 EST (Mon)
From: gz@spt.entity.com (Gail Zacharias)
On another issue: I disagree that there needs to be a protocol for
dumping/loading structures. I think that now that CLOS is in the language,
structures should only be used for doing simple things simply. If you
really need a complex initialization protocol you should use defclass and
not defstruct. But if you just want a container with some slots, you
shouldn't be forced to write loader functions just because you chose to
make it a structure instead of a vector.
Actually, since structures are just another meta-class, this really
isn't any different than the need for a protocol for CLOS objects.
Because the programmer is the only one to know whether an object
(structure or not!!) is "just a container with some slots", or part of a
more integrated data structure, I feel it is dangerous to just ASSUME
you know how to dump it. That doesn't mean it has to be HARD to do it.
We could either provide a standard dumping function, or a small bit of
DEFSTRUCT syntax:
(defstruct (frob :dumper-function) ;; Dumps all slots
(a-slot)
(another-slot))
(defstruct (frob2 (:dumper-function lookup-frob2)) ;; Does name lookup,
;; creating if needed
(name)
(a-slot)
(another-slot))
Remember, there's already a lot of pre-CLOS code out there in the world.
I'd rather get an error, and have to make a trivial change to the
DEFSTRUCT, than have it silently do the wrong thing.
------- End undelivered message -------
∂28-Nov-88 2049 mmdf@relay.cs.net Failed mail (msg.aa16544)
Received: from aramis.rutgers.edu by SAIL.Stanford.EDU with TCP; 28 Nov 88 20:49:08 PST
Received: from GW1.CS.NET by aramis.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA11090; Mon, 28 Nov 88 23:48:23 EST
Message-Id: <8811290448.AA11090@aramis.rutgers.edu>
Date: Mon, 28 Nov 88 20:56:11 EST
From: RELAY Mail System (MMDF) <mmdf@relay.cs.net>
Sender: mmdf@relay.cs.net
Subject: Failed mail (msg.aa16544)
To: @aramis.rutgers.edu:CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Your message could not be delivered to
'stick@ohio-state.edu (host: ohio-state.edu) (queue: smtp-ns)' for the following
reason: ' <stick@ohio-state.edu>... User unknown'
Your message follows:
Received: from aramis.rutgers.edu by RELAY.CS.NET id aa16544;
28 Nov 88 14:30 EST
Received: from SAIL.STANFORD.EDU by aramis.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA18139; Mon, 28 Nov 88 14:22:29 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂28-Nov-88 2200 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 2200 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 22:00:26 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01379g; Mon, 28 Nov 88 21:58:13 PST
Received: by bhopal id AA00442g; Mon, 28 Nov 88 21:57:06 PST
Date: Mon, 28 Nov 88 21:57:06 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290557.AA00442@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 22 Nov 88 19:27 EST <19881123002752.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
This is all fine with me now, except for one odd addition you made: the
additional return value for the iterator over packages. Whereas it
used to be:
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED, or unspecified for
;; the DO-ALL-SYMBOLS case.
. . .
it is now:
An invocation (<next-fn>) returns four values as follows:
;; 1. a boolean indicating whether a symbol is returned (T says yes)
;; 2. a symbol (accessible in the indicated package)
;; 3. a package (in which the symbol is accessible)
;; 4. the accessibility type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED
. . .
First off, I much prefer that such information be passed as the 4th
value, rather than disturbing the original ordering (since I have code
that needs the accessibility type, particularly when doing DO-SYMBOLS;
but never have code that needs merely "a package"). But of what value
is it anyway? simply saying that it is "a package" in which the symbol
is "accessible" doesn't really tell one anything important. For example,
in DO-SYMBOLS over package FOO, a given symbol may be inheritable from
three distinct packages "used" by FOO; but your prescription here makes
it legal simply to return FOO each time. Maybe you meant "present"
rather than "accessible"? Even then, I'm not sure how you would specify
it to mean what I suspect you want it to mean.
-- JonL --
------- End undelivered message -------
∂28-Nov-88 2239 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 28 Nov 88 22:39:15 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA15530; Mon, 28 Nov 88 22:37:45 PST
Message-Id: <8811290637.AA15530@trout.nosc.mil>
Date: 28 Nov 88 19:01:14 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Mon Nov 28 18:17:47 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA12007; Mon, 28 Nov 88 18:17:43 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST
Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: common-lisp@sail.stanford.edu
Message-Id: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
If you look at most implementations, and at the examples on pg 351, then
you'd think it should be `(a . b)
However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
I tried Ibuki, Franz, Lucid, and Genera.
In all of them evaluating '`(,@'(a . b)) => `(a . b).
In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil)
while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b)
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
∂28-Nov-88 2247 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 2247 CL-Cleanup-mailer Issue: SETF-PLACES (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 22:47:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01399g; Mon, 28 Nov 88 22:45:27 PST
Received: by bhopal id AA00476g; Mon, 28 Nov 88 22:44:19 PST
Date: Mon, 28 Nov 88 22:44:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290644.AA00476@bhopal>
To: Gray@DSG.csc.ti.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Tue, 22 Nov 88 18:38:59 CST <2805237539-1438981@Kelvin>
Subject: Issue: SETF-PLACES (version 1)
re: There is a non-editorial issue here: are FBOUNDP and SYMBOL-FUNCTION
required to accept anything returned by UNDERLYING-NAME, or are they
only meaningful for symbols? On Lisp Machines these are primitives for
accessing symbol definition cells while other functions, FDEFINEDP and
FDEFINITION, accept any function spec.
Yes, the current CLOS spec requires FBOUNDP and SYMBOL-FUNCTION to
accept "function specs"; see for example the documentation in 88-002R
of ENSURE-GENERIC-FUNCTION. This proposal (SETF-PLACES, or whatever
name you want to call it) does not purport to change that requirement
for those implementations that already have "function specs" implemented.
[Incidentally, the earlier SETF-FUNCTION-VS-MACRO proposal failed to
address the SYMBOL-FUNCTION issue.]
re: For consistency, shouldn't this be accepted by all function-defining
macros and special forms? Besides DEFMETHOD and DEFGENERIC, there are
DEFUN, FLET, LABELS, GENERIC-FLET, GENERIC-LABELS, WITH-ADDED-METHODS,
and DEFCLASS. I also can't find any mention of the special form
FUNCTION in the proposal; shouldn't it also accept function specifiers?
Most certainly not! This is the whole point of this proposal -- to
limit non-symbol names to precisely the one place in CLOS where it is
extremely difficult to use just one symbol, namely in the SETF generic
methods. Note that DEFMETHOD, DEFGENERIC etc doesn't define "a function",
but rather a piece of one.
The whole reason that anyone outside the Brothers-of-MIT-LispMachine
community acceed to compound names for setf methods is that it was very
difficult to use a single symbol for specifying what "piece" of what
"function" is meant. Further, by Gregor's argumentation, the non-symbol
name need only appear in the outer CLOS syntax, since DEFMETHOD is just
a macro which will expand out into something more primitive (which in
many implementations will be a hoked-up symbol a la the example code.)
Similarly, requiring a few functional entries of CLOS to accommodate a
limited function spec notion is nowhere near the burden on other
implementations that extending to full functions specs would be.
Looking ahead, I see that several more of the "Brothers-..." have
made the same request, which basically boils down to requiring all
implementations to have the essence of function specs by "trojan horse".
Contrary to what has been said, the X3J13 group is not adamantly against
SETF-FUNCTIONS -- rather, they are balking at the notion of lists as
function names. I fervently hope that in the future some improved
version of function specs -- definition specs -- will be accepted into
Common Lisp; but in my opinion, the consensus to do it now just isn't
there. It just does no good to pretend that this one itsy-bitsy,
teensy-weensy extension isn't full functions specs; the issues seen
so clearly by many are:
(1) once you've had to dicker around with all the places in an
implementation to make (SETF <foo>) uniformly acceptable as
a function name, you have basically done all the necessary
work for "functions specs". So if it walks like a duck,
quacks like a duck . . .
(2) functions specs [and indeed "definition specs"] break a very
fundamental notion people have about function names -- that
only symbols will do; it will take some longer period of time
to get them used to the newer ideas.
-- JonL --
------- End undelivered message -------
∂28-Nov-88 2305 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 2305 CL-Cleanup-mailer Issue: SETF-PLACES (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 23:05:39 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01405g; Mon, 28 Nov 88 23:03:29 PST
Received: by bhopal id AA00498g; Mon, 28 Nov 88 23:02:21 PST
Date: Mon, 28 Nov 88 23:02:21 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290702.AA00498@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 22 Nov 88 19:49 EST <19881123004923.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: SETF-PLACES (version 1)
re: Similarly, LABELS and FLET should accept "specs", since GENERIC-LABELS
and GENERIC-FLET do. This would eliminate the non-portability of
the FLET of setf:3.bar.middle-ref example.
I don't think so. The point of the non-portable example was just to
illustrate the implementational structure of one kind of underlying
name, and its consequences outside the demands of CLOS. In real CLOS
usage, GENERIC-FLET would be used rather than FLET; and that kind of code
would be portable [and it *is* the needs of CLOS that is the excuse for
doing this kludge now -- not because we think it is such a great thing
in its own right].
Also, SETF functions currently aren't accessible via FUNCTION or
SYMBOL-FUNCTION. Namely, you have to say (SETF (AREF ...) val); there
is no form that you can evaluate to get a functional definition for the
SETF method. By not making the world's most general extension here --
by admitting that you probably won't be able to define a generic setf
function portably with FLET, but instead will use GENERIC-FLET -- we are
not adding any limitations on what is currently doable in Common Lisp.
-- Jonl --
------- End undelivered message -------
∂28-Nov-88 2312 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 2312 CL-Cleanup-mailer Issue: SETF-PLACES (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 23:12:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01411g; Mon, 28 Nov 88 23:10:01 PST
Received: by bhopal id AA00511g; Mon, 28 Nov 88 23:08:52 PST
Date: Mon, 28 Nov 88 23:08:52 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290708.AA00511@bhopal>
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Tue, 22 Nov 88 21:13:26 EST <8811230216.AA02071@lucid.com>
Subject: Issue: SETF-PLACES (version 1)
re: . . . The current proposal looks like a recipe for
disaster, since this name/spec distinction is going to confuse people and
raise lots of questions about which can be used where.
The "disaster" is _already_ there -- in 88-002R. Have you read it?
You have to pay careful attention to the whole thing, or else you may
not remember where it says what can be used where. This proposal --
(1) to clear up the setf functions issue and (2) to limit the
lists-as-names issue -- neither adds nor detracts from that potential
source of confusion.
-- JonL --
------- End undelivered message -------
∂28-Nov-88 2324 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
28-Nov-88 2324 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Nov 88 23:24:36 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01417g; Mon, 28 Nov 88 23:22:35 PST
Received: by bhopal id AA00546g; Mon, 28 Nov 88 23:21:27 PST
Date: Mon, 28 Nov 88 23:21:27 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290721.AA00546@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanuP@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: masinter.pa@Xerox.COM's message of 23 Nov 88 13:41 PST <881123-134244-13159@Xerox>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)
re: I would characterize this as : "There was strong opposition to this
proposal from one group Common Lisp users trying to run multiple
implementations at their site." and include the above phrase in the
discussion section.
How large was this "vocal" group of users? 2? 3? 200? 300?
-- JonL --
------- End undelivered message -------
∂29-Nov-88 0028 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:28:19 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA02148; Tue, 29 Nov 88 00:25:57 PST
Date: Tue, 29 Nov 88 00:25:57 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811290825.AA02148@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA02141; Tue, 29 Nov 88 00:25:57 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14998; Tue, 29 Nov 88 00:27:11 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST
Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290810.AA00624@bhopal>
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂29-Nov-88 0014 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 0014 Common-Lisp-mailer inconsistency in backquote spec?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST
Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290810.AA00624@bhopal>
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
------- End undelivered message -------
∂29-Nov-88 0356 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 29 Nov 88 03:56:19 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA21510; Tue, 29 Nov 88 03:55:03 PST
Message-Id: <8811291155.AA21510@trout.nosc.mil>
Date: 29 Nov 88 03:40:14 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Tue Nov 29 00:46:49 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA18662; Tue, 29 Nov 88 00:46:32 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST
Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290810.AA00624@bhopal>
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂29-Nov-88 0404 mmdf@RELAY.CS.NET Failed mail (msg.da01788)
Received: from RELAY.CS.NET (GW1.CS.NET) by SAIL.Stanford.EDU with TCP; 29 Nov 88 04:04:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id an00562; 29 Nov 88 7:06 EST
Date: Tue, 29 Nov 88 6:52:29 EST
From: RELAY Mail System (MMDF) <mmdf@RELAY.CS.NET>
Sender: mmdf@RELAY.CS.NET
Subject: Failed mail (msg.da01788)
To: @RELAY.CS.NET:CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
After 7 days (150 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
@sorak.kaist.ac.kr:jkim@csd.kaist.ac.kr (host: sorak.kaist.ac.kr) (queue: kaist)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message follows:
Received: from relay.cs.net by RELAY.CS.NET id da01788; 23 Nov 88 0:37 EST
Received: from sail.stanford.edu by RELAY.CS.NET id aa18955; 22 Nov 88 17:48 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 14:13:35 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 22 Nov 88 14:06:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 295632; 20 Nov 88 17:40:49 EST
Date: Sun, 20 Nov 88 17:30 EST
From: "Robert W. Kerns" <RWK@f.ila.dialnet.symbolics.com>
Subject: How to reach Robert Kerns
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>,
Cris Perdue <cperdue@SUN.COM>
Cc: cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <19881118232718.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19881120223020.0.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Fri, 18 Nov 88 18:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
That address is correct. Try using % to indirect through a better
mailer. For instance,
rwk%f.ila.dialnet.symbolics.com@riverside.scrc.symbolics.com
is likely to work.
You could also try rwk@ai.ai.mit.edu (he has a mailbox there, I
don't know how often he reads it).
That forwards to ILA these days, but it is a convenient address for
those with mailers that haven't QUITE made it into the domain era.
I read it every couple of days or so, unless I'm in some other country.
(Or some other planet, as the case may be).
Alternatively, try cruising around Boston Harbor in a rubber
raft until you sight Bob's boat.
Dress warmly, and look closely, because I'm tucked away in a snug corner
of the harbor for the winter!
As a better alternative, may I suggest you look in Aruba or Tahiti? You
won't find me unless you wait around a few years, but I can guarentee
you a better time than paddling around Boston Harbor this time of year!
∂29-Nov-88 0721 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 0721 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 07:21:41 PST
Received: by ti.com id AA14505; Tue, 29 Nov 88 09:19:52 CST
Received: from Kelvin by tilde id AA21650; Tue, 29 Nov 88 09:15:14 CST
Message-Id: <2805808638-9694447@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 29 Nov 88 09:17:18 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
In-Reply-To: Msg of Mon, 28 Nov 88 14:50:28 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Examples:
>
> (SETQ MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
> (PROCLAIM '(CONSTANT MEMORY-SIZE))
I'm still having trouble with this approach. First, our compiler would
issue a warning on the SETQ that MEMORY-SIZE is not a defined variable
and is being assumed to be special. Is such a warning not appropriate?
It is very useful for catching spelling errors that could go unnoticed
otherwise. Second, what happens the second time you load this file?
Since the name has been proclaimed to be a constant, the SETQ would
signal an error this time.
------- End undelivered message -------
∂29-Nov-88 0751 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 0751 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 07:51:23 PST
Received: by ti.com id AA14699; Tue, 29 Nov 88 09:49:04 CST
Received: from Kelvin by tilde id AA21949; Tue, 29 Nov 88 09:31:49 CST
Message-Id: <2805809644-9754862@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 29 Nov 88 09:34:04 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Robert W. Kerns" <RWK@f.ila.dialnet.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Cris Perdue <cperdue@sun.com>, cl-compiler@sail.stanford.edu
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES:SPECIFY, V3
In-Reply-To: Msg of Mon, 28 Nov 88 21:34 EST from Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
> Because of hash tables, and the other coalescence screws! Actually, EQL
> isn't right, either, because EQ hash tables exist. EQ is the right one.
Do you really intend that coalescing of floating point constants should
never be permitted just because someone might have used them as keys in
an EQ hash table?
> I think current practice is predicated (no pun
> intended) on a false assumption: that it improves the "performance" of
> the program (either the size of the files, or of the loaded files, or
> whatever) in some significant way. I don't believe that anymore,
Obviously it does improve performance, so I guess the key word is
"significant" -- does it happen often enough to be worthwhile? That is
hard to answer since it will vary greatly from program to program; some
won't be helped at all, but some rely on it so heavily that the
programmer might want to code it differently if he knew that the
constants were not going to be coalesced.
Code optimization does not involve doing big, significant, improvements,
as much as doing a lot of little improvements. I don't think we should
prevent implementations from doing a particular optimization just
because it might not appear to big win for everyone.
------- End undelivered message -------
∂29-Nov-88 0834 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 0834 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:34:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA14125; Tue, 29 Nov 88 09:33:46 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12029; Tue, 29 Nov 88 09:33:42 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811291633.AA12029@defun.utah.edu>
Date: Tue, 29 Nov 88 09:33:41 MST
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Tue, 29 Nov 88 09:17:18 CST
Actually, the same problems occurred to me while I was editing the
writeup. One solution that occurs to me is to put the PROCLAIM
CONSTANT -before- the SETQ, and say that it is not an error to SETQ a
variable that has been proclaimed CONSTANT but is unbound (that is,
hasn't been initialized yet). That still doesn't entirely address the
problem of reloading files, but at least it would provide a mechanism
so that DEFCONSTANT would be able to make redefining constants work.
(I thought putting this in would go beyond a mere editorial change,
which is why I didn't.)
Your solution of temporarily proclaiming the variable SPECIAL might
suppress the SETQ'ing warning in some implementations, but I think it
would also be just as appropriate for a compiler to emit a warning
message when a variable is changed from CONSTANT to SPECIAL or vice
versa, so it might lose in other implementations.
-Sandra
-------
------- End undelivered message -------
∂29-Nov-88 0813 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 0813 Common-Lisp-mailer Common Lisp for SUNS
Received: from red.ipsa.dnd.ca by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:13:45 PST
Received: by red.ipsa.dnd.ca; (5.54/4.7)
id AA01479; Tue, 29 Nov 88 11:14:29 EST
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Message-Id: <8811291614.AA01479@red.ipsa.dnd.ca>
To: common-lisp@sail.stanford.edu
Subject: Common Lisp for SUNS
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
------- End undelivered message -------
∂29-Nov-88 0920 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 0920 CL-Cleanup-mailer Re: Issue: SETF-PLACES (version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:20:12 PST
Received: by ti.com id AA15233; Tue, 29 Nov 88 11:19:22 CST
Received: from Kelvin by tilde id AA24807; Tue, 29 Nov 88 11:13:21 CST
Message-Id: <2805815733-10120696@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 29 Nov 88 11:15:33 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: SETF-PLACES (version 1)
In-Reply-To: Msg of Mon, 28 Nov 88 22:44:19 PST from Jon L White <jonl@lucid.com>
> Yes, the current CLOS spec requires FBOUNDP and SYMBOL-FUNCTION to
> accept "function specs";
...
> re: For consistency, shouldn't this be accepted by all function-defining
> macros and special forms?
...
> Most certainly not! This is the whole point of this proposal -- to
> limit non-symbol names to precisely the one place in CLOS where it is
> extremely difficult to use just one symbol, namely in the SETF generic
> methods. Note that DEFMETHOD, DEFGENERIC etc doesn't define "a function",
> but rather a piece of one.
But if you are going extend the lowest level primitives, FBOUNDP and
SYMBOL-FUNCTION, to accept function specs, then I don't see that you
gain very much by saying that higher-level macros and special forms
won't accept them. DEFUN would typically be implemented as a macro that
expands into (SETF (SYMBOL-FUNCTION ...) ...), so if SYMBOL-FUNCTION
accepts function specs, wouldn't DEFUN also accept them automatically?
If the intent is to limit the amount of change to implementations that
don't already support function specs, it seems like it would be easier
to leave FBOUNDP and SYMBOL-FUNCTION alone, introduce FDEFINEDP and
FDEFINITION, and then say that DEFMETHOD, DEFGENERIC, etc. use
FDEFINITION instead of SYMBOL-FUNCTION. A portable definition using
your conversion function is:
(DEFUN FDEFINITION (FUNCTION-SPEC)
(SYMBOL-FUNCTION (UNDERLYING-NAME FUNCTION-SPEC)))
(DEFUN FDEFINEDP (FUNCTION-SPEC)
(FBOUNDP (UNDERLYING-NAME FUNCTION-SPEC)))
(DEFSETF FDEFINITION (FUNCTION-SPEC) (DEFINITION)
`(SETF (SYMBOL-FUNCTION (UNDERLYING-NAME ,FUNCTION-SPEC))
,DEFINITION))
This approach also minimizes changes for those of use who do already
support function specs. The next question is whether there is really a
need for the user to know about UNDERLYING-NAME. The only use I can
think of would be to do a GET on the underlying symbol, or to use it as
a key in an EQ hash table, but neither of those would be portable since
UNDERLYING-NAME could return a non-symbol on some implementations. We
could instead introduce a portable interface to associating properties
with function-specs:
(DEFUN FUNCTION-SPEC-GET (FUNCTION-SPEC PROPERTY &OPTIONAL DEFAULT)
(GET (UNDERLYING-NAME FUNCTION-SPEC) PROPERTY DEFAULT))
(DEFSETF FUNCTION-SPEC-GET (FUNCTION-SPEC PROPERTY &OPTIONAL DEFAULT) (VALUE)
`(SETF (GET (UNDERLYING-NAME ,FUNCTION-SPEC) ,PROPERTY) ,VALUE))
> Looking ahead, I see that several more of the "Brothers-..." have
> made the same request, which basically boils down to requiring all
> implementations to have the essence of function specs by "trojan horse".
But I've just shown you how to implement the essence of function specs
in only eleven lines of code. Well, make that thirteen because you
probably want this too:
(DEFUN FUNDEFINE (FUNCTION-SPEC)
(FMAKUNBOUND (UNDERLYING-NAME FUNCTION-SPEC)))
But that's it; it's not really that big a deal. There is still a
separate question of where you want FDEFINITION etc. to be used instead
of SYMBOL-FUNCTION etc. Mightn't it be easier to change them all
consistently than to have to document which forms of function names can
be used where?
> Contrary to what has been said, the X3J13 group is not adamantly against
> SETF-FUNCTIONS -- rather, they are balking at the notion of lists as
> function names. I fervently hope that in the future some improved
> version of function specs -- definition specs -- will be accepted into
> Common Lisp; but in my opinion, the consensus to do it now just isn't
> there. It just does no good to pretend that this one itsy-bitsy,
> teensy-weensy extension isn't full functions specs; the issues seen
> so clearly by many are:
> (1) once you've had to dicker around with all the places in an
> implementation to make (SETF <foo>) uniformly acceptable as
> a function name, you have basically done all the necessary
> work for "functions specs". So if it walks like a duck,
> quacks like a duck . . .
> (2) functions specs [and indeed "definition specs"] break a very
> fundamental notion people have about function names -- that
> only symbols will do; it will take some longer period of time
> to get them used to the newer ideas.
But if you accept lists to name functions in certain contexts, how does
it really help to say that they aren't "function specs"? Since I'm
obviously coming from a very biased perspective, I don't see anything
un-esthetic about using lists as function names. It's certainly a
concept that has been around a long time and has proven very useful.
------- End undelivered message -------
∂29-Nov-88 0922 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 0922 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:22:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 499263; Tue 29-Nov-88 12:20:03 EST
Date: Tue, 29 Nov 88 12:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811290557.AA00442@bhopal>
Message-ID: <19881129171957.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 28 Nov 88 21:57:06 PST
From: Jon L White <jonl@lucid.com>
This is all fine with me now, except for one odd addition you made: the
additional return value for the iterator over packages.
The reason was that I don't see how the accessibility type means anything at
all except relative to a package. This is not an issue when the <package-list>
argument is of length 1, since the <package> value will always be the sole
element of that list. But when iterating over several packages, or all
packages, to use the accessibility type for anything you need to know which
package the iteration is operating on.
in DO-SYMBOLS over package FOO, a given symbol may be inheritable from
three distinct packages "used" by FOO; but your prescription here makes
it legal simply to return FOO each time.
Not just legal, but required. Sorry about the ambiguity.
First off, I much prefer that such information be passed as the 4th
value, rather than disturbing the original ordering (since I have code
I don't care about the order. I didn't realize that you did.
Sorry about the unclarity, when I said
;; 2. a symbol (accessible in the indicated package)
;; 3. a package (in which the symbol is accessible)
;; 4. the accessibility type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED
I meant that those three values were to be interpreted jointly. How
about this clarification:
The package value is one of the packages present or named in the
<package-list> argument. The meaning of the second, third, and fourth
values is that the returned symbol is accessible in the returned package
in the specified way: present and not exported if :INTERNAL, present
and exported if :EXTERNAL, or not present and inherited from some other
package and not shadowed if :INHERITED.
I think the alternative to returning a package-type value is to make
the accessibility-type value unspecified whenever the <package-list>
argument has more one element. I am loath to do that.
What shall we do?
------- End undelivered message -------
∂29-Nov-88 0936 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@clam.sun.com
------- Begin undelivered message: -------
29-Nov-88 0936 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:24 PST
Received: by ti.com id AA15345; Tue, 29 Nov 88 11:34:48 CST
Received: from Kelvin by tilde id AA25085; Tue, 29 Nov 88 11:28:10 CST
Message-Id: <2805816627-10174414@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 29 Nov 88 11:30:27 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
In-Reply-To: Msg of Tue, 29 Nov 88 09:33:41 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Your solution of temporarily proclaiming the variable SPECIAL might
> suppress the SETQ'ing warning in some implementations, but I think it
> would also be just as appropriate for a compiler to emit a warning
> message when a variable is changed from CONSTANT to SPECIAL or vice
> versa, so it might lose in other implementations.
Such a warning would not be appropriate if we decide that that is the
way to initialize a constant. The only alternative I see is to go back
to the idea of having a new macro analogous to DEFPARAMETER for both
declaring and initializing not-wired constants.
------- End undelivered message -------
∂29-Nov-88 0906 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 0906 Common-Lisp-mailer Common Lisp for SUNS
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:04:27 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 29 Nov 88 12:02:03 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 29 Nov 88 12:02:57 EST
Date: Tue, 29 Nov 88 12:03 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881129170307.7.BARMAR@OCCAM.THINK.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
Sun Common Lisp currently is Lucid Common Lisp. There were rumors last
year that they would be switching to Franz (who makes Allegro CL), but
this doesn't appear to have happened.
Kyoto CL is not generally considered a high-performance Lisp. Its major
feature is its portability, since it is written mostly in C and its
compiler uses C as the intermediate language. It is also well-known for
being very faithful to CLtL, implementing all and only what the book
says.
barmar
------- End undelivered message -------
∂29-Nov-88 0937 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 0937 Common-Lisp-mailer inconsistency in backquote spec?
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:59 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 12:34:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 12:35:41 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 12:34:10 EST
Received: by joplin.think.com; Tue, 29 Nov 88 12:35:36 EST
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Message-Id: <8811291735.AA00711@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
------- End undelivered message -------
∂29-Nov-88 1045 Mailer@MCC.COM Message of 28-Nov-88 10:59:30
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:45:31 PST
Date: Tue 29 Nov 88 11:13:11-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Message of 28-Nov-88 10:59:30
Message undelivered after 1 day -- will try for another 2 days:
CL-Object-Oriented-Programming@Hal.CAD.MCC.com: Cannot connect to host
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 28 Nov 88 10:59:32-CST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
-------
∂29-Nov-88 1049 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1049 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:49:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 29 NOV 88 10:45:32 PST
Date: 29 Nov 88 10:44 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LIST-TYPE-SPECIFIER (version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881129-104532-5426@Xerox>
Since Mike Beckerle has declined to pursue this issue, it will need another
volunteer to produce a new version; otherwise I will mark it as
"withdrawn".
----- Begin Forwarded Messages -----
Return-Path: <mikeb@boston.goldhill.com>
Received: from goldhill.com ([128.168.1.211]) by Xerox.COM ; 29 NOV 88
08:05:42 PST
Received: from BOSTON.GOLDHILL.COM by goldhill.com; Tue, 29 Nov 88 10:49:54
EST
Message-Id: <8811291549.AA12760@goldhill.com>
Date: Tue, 29 Nov 88 10:49:17
From: mikeb@boston.goldhill.com
To: masinter.PA
Larry,
I am not inclined to pursue list-type-specifier further.
...mike beckerle
----- End Forwarded Messages -----
------- End undelivered message -------
∂29-Nov-88 1009 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 1009 Common-Lisp-mailer Common Lisp for SUNS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:09:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01681g; Tue, 29 Nov 88 10:06:59 PST
Received: by bhopal id AA01309g; Tue, 29 Nov 88 10:05:50 PST
Date: Tue, 29 Nov 88 10:05:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8811291805.AA01309@bhopal>
To: bill@red.ipsa.dnd.ca
In-Reply-To: Bill Pase's message of Tue, 29 Nov 88 11:14:29 EST <8811291614.AA01479@red.ipsa.dnd.ca>
Subject: Common Lisp for SUNS
Cc: common-lisp@sail.stanford.edu
I'm not the right person to send you benchmark data on Lucid Common
Lisp, but I thought I should mention that Sun Common Lisp is Lucid
Common Lisp. (Lucid makes it, Sun sells it.)
Also, I can give some general advice about benchmarks:
(1) Be sure to note the releases being compared. For example, LCL
Version 3.0 is significantly different from LCL Version 2.1. We
added a second compiler, an ephemeral garbage collector,
multi-tasking, better inline floating point code, new interrupts,
new I/O, etc., etc.
(2) Be sure that the person who produced the benchmark values
understands the benchmarks and the lisp being tested. Proper use
of declarations and compiler settings can sometimes produce
order-of-magnitude differences. Also, for example, the use of a
feature such as ephemeral garbage collection may reflect a
decision to accept a somewhat increased running time in order to
avoid detectable pauses for GC. Turning EGC off may result in
different (usually faster) benchmark values, and might or might
not be appropriate for various applications. You need to
understand how you're going to use the lisp to know what settings
are appropriate.
(3) Ask for the *precise* techniques used to obtain the benchmarks,
including processor speed, memory size, load on the machine, etc.
I know that some of the people at Lucid have produced benchmark
figures using what we call the "low-mode" -- we run each
benchmark about 20 times or more, then use some statistics to
produce a number one could expect to be the low value obtained
in a typical set of about 3 runs. (We didn't want to just
scrounge for the lowest value, since that's not always
reproducible, yet did want to give a fair indication of the
performance possible.) I'm pretty sure the techniques used are
distributed with the benchmark numbers.
(4) If performance is critical, explain this to the vendor. For
example, Lucid is now productizing tools to reorganize your code
based on an analysis of its dynamic performance, since code and
data locality can have order-of-magnitude affects on real-life
applications. Remember that you are going to be running
applications day-to-day, and not just benchmarks. Support in
this area can be as crucial as the underlying speed of the lisp!
Happy hunting,
jlm
------- End undelivered message -------
∂29-Nov-88 1035 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 1035 Common-Lisp-mailer Re: inconsistency in backquote spec?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST
Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 29 Nov 88 10:23:29 PST (Tuesday)
Subject: Re: inconsistency in backquote spec?
From: "Larry_Masinter.PARC"@Xerox.COM
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.EDU
In-Reply-to: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28
Nov 88 18:12
Message-ID: <881129-102742-5383@Xerox>
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
Status: PASSED
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
------- End undelivered message -------
∂29-Nov-88 1050 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 1050 Common-Lisp-mailer inconsistency in backquote spec?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST
Date: Tue, 29 Nov 88 13:55 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: jonl@lucid.com, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811290810.AA00624@bhopal>
Message-ID: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I agree with this (I think there's a CL cleanup that specifies this
behavior for APPEND and NCONC), and therefore the Lucid backquote
implementation is inconsistent with the definition of APPEND.
(setq d '(a . b))
`(,@d)
`(,@d . nil)
(append [,@d] 'nil)
(append d 'nil)
(append '(a . b) 'nil)
should be (a), as in your example above.
However, it was (a . b) on the version I tried - I didn't try the APPEND
case itself, so maybe in a later version both were made consistent.
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
------- End undelivered message -------
∂29-Nov-88 1127 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host(s) replied to these mail addresses:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
spar-common-lisp@SPAR-20.SPAR.SLB.COM
------- Begin undelivered message: -------
29-Nov-88 1127 Common-Lisp-mailer Re: Common Lisp for SUNS
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST
Received: by tut.cis.ohio-state.edu (5.59/2.881128)
id AA25824; Tue, 29 Nov 88 14:12:36 EST
Date: Tue, 29 Nov 88 14:12:36 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu>
To: barmar@think.com
Cc: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
>
>Kyoto CL is not generally considered a high-performance Lisp. Its major
>feature is its portability, since it is written mostly in C and its
>compiler uses C as the intermediate language. It is also well-known for
>being very faithful to CLtL, implementing all and only what the book
>says.
We're in the process of coming up with a decision on what lisp to get
for the University, and have been looking at Ibuki, Franz, and Envos
(and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has
been benchmarking them on Sun-3's and Sun-4's, and we've noticed that
in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind
of amazed by this, until we realised that Ibuki uses the native C
compiler, which is optimising for the SPARC architecture on the -4,
while none of the others were. This wasn't an across-the-board
speedup, just for some of the things we tried. I'd pretty much agree
with your other assessment of Kyoto CL, modulo the fact that Ibuki has
extended it somewhat (folding in the new error system, for example).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
------- End undelivered message -------
∂29-Nov-88 1138 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 1138 Common-Lisp-mailer inconsistency in backquote spec?
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: gls@Think.COM, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291735.AA00711@joplin.think.com>
Message-ID: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Or, you could say that the list following a ,@ cannot be dotted.
Either way, I think, requires a minor clarification in the CL spec.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
------- End undelivered message -------
∂29-Nov-88 1253 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1253 CL-Compiler-mailer Re: Compilation issues
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 12:52:14 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06983; 29 Nov 88 18:29 GMT
Date: Tue, 29 Nov 88 18:31:39 GMT
Message-Id: <14807.8811291831@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Compilation issues
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, CL-Compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Mon, 28 Nov 88 12:47 EST
> I still have severe problems with a number of the issues on the table.
> Among them CONSTANT-COMPILABLE-TYPES, CONSTANT-CIRCULAR-COMPILATION,
> CONSTANT-MODIFICATION, and CONSTANT-ARRAY-ATTRIBUTES.
Just so. It's almost impossible to follow the discussion even with
the aid of some fairly intelligent mail software.
> If file compilers have problems, let's describe those problems and then
> fix them. But in-core compilers do not have most of the problems that
> file compilers have, so if you want to propose changing those in -any-
> way, you'd better describe clearly what problem you want to fix, and
> motivate clearly why your solution is worth the incompatible change you'll
> be proposing.
Note too that at least one of the compiler-only systems (PopLog) has
in-core compile only: it doesn't compile files. And I think that is
a reasonable way to go. But some things have been justified on the
gounds that some systems are compile-only so that the semantics of
compilation have to apply to EVAL too. But it's really COMPILE-FILE
that must have the unusual semantics.
-- Jeff
------- End undelivered message -------
∂29-Nov-88 1256 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1256 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 12:56:00 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA00628; Tue, 29 Nov 88 12:57:50 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA09900; Tue, 29 Nov 88 12:54:26 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA11100; Tue, 29 Nov 88 12:55:19 PST
Date: Tue, 29 Nov 88 12:55:19 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811292055.AA11100@clam.sun.com>
To: Gray@DSG.csc.ti.com, sandra%defun@cs.utah.edu
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
Cc: cl-compiler@sail.stanford.edu
> > Examples:
> >
> > (SETQ MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
> > (PROCLAIM '(CONSTANT MEMORY-SIZE))
>
> I'm still having trouble with this approach. . . .
I'd like to second David Gray's comments. The Lucid compiler
also warns in cases like this, and I think for good reasons.
This example also violates the idea of definition before use.
------- End undelivered message -------
∂29-Nov-88 1258 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1258 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 12:54:02 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07164; 29 Nov 88 18:50 GMT
Date: Tue, 29 Nov 88 18:52:35 GMT
Message-Id: <14858.8811291852@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, CL-Compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Mon, 28 Nov 88 13:00 EST
On the whole, I prefer this, more conservative, approach.
> The target environment of code compiled by the COMPILE-FILE function
> may be very different than the environment in which the compilation
> occurred. As such, it is not generally possible to reliably preserve
> object identity or sharing (under EQL) of constants occurring in
> programs processed by COMPILE-FILE.
> Current practice:
> Cost to Imlementors:
We might want to remember that KCL represents a fairly large slice
of current use and that it doesn't do some of the things some of the
proposals suggest. KCL dumps constants by printing them. The dump/
load process doesn't do anything fancier than you can do with PRINT
and READ. And READ, like LOAD, may bring constants into a different
environment. There is also a long tradition that PRINT prints things
so they can be read back in (while PRINC, say, does not). So I am
uncomfortable with proposals that make dump/load and print/read very
different beasts.
> Cost to Users:
>
> Any serious portable code is probably already compatible with this
> proposal.
I'm not sure what "serious" is supposed to signify. What's the
difference between "serious protable code" and just "portable code"?
------- End undelivered message -------
∂29-Nov-88 1321 Mailer failed mail returned
To: X3J13-mailer
The following message was undeliverable to the address(es) below
because the destination Host Name(s) are Unknown:
hemphill@NRL-AIC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1235 X3J13-mailer ISO Meeting Report
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Fellow Colleagues:
The following is my report on the November ISO meeting. I am sending
this now for several reasons. First, because it is fresh in my mind.
Second, because the events are a little more dramatic than usual.
Third, because one outcome was the cancellation of the January ISO
meeting in Hawaii.
The US Delegation consisted of Bob Mathis, Thom Linden, Patrick
Dussud, Gregor Kiczales, and myself. The meeting was held at the
Building of the European Community in Brussels, Belgium. It was held
Monday and Tuesday, November 21 and 22.
Attending were France, The Netherlands, Germany, Japan, the UK, and
the US.
The US presented its position statement, which is as follows:
************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. The
near term standardization of ISO Common Lisp would have substantial
positive impact on the acceptance of existing commercial Lisp
implementations and on the viability of future Lisp dialects as
vehicles for emerging applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
************************************************************************
In addition, we proposed the following resolution:
************************************************************************
The U.S. proposes the following ISO WG16 resolution:
It is important to affirm and strengthen the position of the
international community of users who depend on Common Lisp. It is
also imperative that an international standard for Common Lisp must be
subject to international review and revision.
ISO WG16 resolves to proceed with an ISO Common Lisp standardization
process in the following manner:
* WG16 requests X3J13 to produce an ISO draft standard for Common
Lisp in accordance with SC22 synchronization principles for national
body development.
* The X3J13 drafting procedure will accommodate international public
review as well as U.S. public review. X3J13 will establish a schedule
to allow processing of all public comments.
* The timetable for forwarding a draft for circulation by WG16 is
December 1989. The U.S. should make every effort to meet this
schedule.
* X3J13 will inform WG16 of its schedules and progress.
************************************************************************
The German Delegation also had a written position statement. It is as
follows:
************************************************************************
The Position of DIN concerning LISP standardization
Herbert Stoyan
University of Konstanz
November 18, 1988
1. Our Goals
When the LISP-standardization process started we were optimistic to reach a
quick result. Now we have to change our feeling. It will take longer than we
have imagined. To speed up the process we want to change some of our position
statements made in Paris.
First, we voted for CommonLISP as a starting point for standardization. We
want to change this commitment into an open one. We join the US that one of
Scheme or CommonLISP (but not both) should be used.
Second, we made a vote for desirable characteristics of the standard. We
regret that not all points went as we desired. But the issues seem to be
mixed: There are language issues and report issues.
Before all the points, we should all agree that standardization is only
partially a language definition activity. We should standardize an existing
language. Therefore we don't like anymore the list of default values for
language components. If we still intend to follow this direction we get
everything but a language which is usable. We don't feel that this was a good
idea. DIN will accept any proposal for a LISP standard and check every part
of it - not only functional objects etc.
Obviously, the goal of standardization is portability. Therefore this issue
deserves most attention. We got here the right mark. The next issue of
standardization seems to be processor conformity. We would like to change our
figure `6' into a `2'. We believe the conformity must be provable: Without a
proof procedure for conformity our work is not complete. Especially, there
has to be a test suite.
The standard report must be technical clear. Therefore a clear semantics is
important. It is the way to achieve portability. We ranked this topic with
`3' and support this vote again. The standard report has to be
understandable. An important means to achieve this is a simple semantics. We
miss understandability as characteristics and again want to stress our figure
`4' here.
A standard report has to be usable. That means, it should be well organized,
it should not be too voluminous, it should be use not too many references to
other parts. Maybe this was meant by `Ease of learning'. We believe that
this characteristic is only an indicator for this quality of the standard.
Therefore we want to change our figure of `12' into a `5'.
Now, concerning the language. A language to be standardized must be
interesting. That must be already - we cannot change it. May be this is what
was meant as `Power'. We want to rank this point at first place in the
language goals we have. Power does not mean to provide everything. A
language which is too large and complex has no power and will not be
appealing. History of programming languages proves that baroque languages
will not last for long. Therefore we want to vote for `Compactness' - but it
is not in the list of characteristics.
If a language is big only because of many concepts which enable variations of
expressions for one and the same thing then the language is defined badly. If
the language contains elements which cannot be combined it should be regarded
as a family of languages. Both dimensions are called orthogonality. We want
to vote for `Orthogonality' - but cannot find it.
There are characteristics of implementations. Issues like efficiency,
consistency interpreter/compiler, stability etc. come in mind. They are goals
for implementors. Good implementors will achieve them - bad implementors wil
fail. These are not goals of standardization.
Ease of implementation is a goal which is always fulfilled with LISP. The art
is to find a way to quality.
2. The Situation
Our original proposal was to standardize a kernel of LISP with parts everybody
will accept readily. This work could be done in 18 month. But there are not
many countries to support this approach.
Richard Gabriel made the point that three languages should not be
standardized. We adopt this position. We have to ask who moved us in the
position where this danger is to be faced. Obviously, it is the pair of
US-activities. It was clear to ANSI that CommonLISP is not ready for
standardization. A de-facto standard ist not a true standard. We want not
decide without studying the latest draft of CommonLISP if it achieved enough
quality. Furthermore, we have the feeling that the activity for standardizing
Scheme was started to contravene the European desire for a clean LISP kernel.
3. Our Proposal
ISO is not an organisation for creating new languages. The maximal thing we
should plan is to change a presented language somewhat. The French have
exposed the three level approach. There seems nobody (with exception of DIN)
who likes the idea.
Therefore: We propose to take the draft reports of CommonLISP and Scheme
and check them for quality of being standardized. If they both have the
quality, we should standardize both of them with ISO. If only one has
the quality we should take this one. If none of the has the quality we
should generate a list of required changes and wait for better drafts. In the
meantime other member bodies are invited to define LISPs which deserve
standardization.
************************************************************************
In summary, they commented that the current ISO process does not seem
to be converging on a standard quickly enough, and that a short-term
standard can produced only by working with an existing dialect and
draft. They proposed that drafts for X3J13 Common Lisp and IEEE Scheme
be considered and measured against several criteria. These are that
the draft be clear and unambiguous, not unacceptably long (< 300 pages
was suggested), and precisely stated. The languages ought to be as
crisp and orthogonal as possible (that is, minimal redundant
features). The German Delegation proper consisted of Klaus Daessler
(Siemens), Dieter Kolb (Siemens), and Herbert Stoyan (University of
Konstanz). Kolb favors Common Lisp and the other two favor Scheme, but
the German position allowed for both to be selected and standardized
by ISO.
No other delegation had a written position statement. The Japanese
Delegation consisted of Professor Ito and Mr Kurokawa. Professor Ito
is primarily concerned about CLOS, but after private discussions I
learned that because of lack of study he did not understand it, and
the expert group that advises him consists of object-oriented
programming researchers who press their own ideas on him.
The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
They responded by remarking that the US position represented a
``preposterous'' change in position by the US and directly
contradicted the agreed-upon work item. This work item was the AFNOR
(French) position which was to standardize a Common-Lisp-like dialect
with no packages, simple lambda-lists, simple arrays, generic
functions without classes, a different multiple value system, and a
different syntax for specials. The US argued that this plan was never
voted on because the convener would not allow it: He exaplined that
because it was a technical proposal, it was subject to discussion as
are all other technical points.
The US further remarked that the US position allowed for multiple
standardized dialects, but the convener denied this was possible under
the current work item and suggested we could try introducing a second
work item.
The French delegation contended that the US plan was to block the ISO
process. They were right in the limited sense that I threatened to
block the standardization of any dialect of Common Lisp that was
neither a superset nor a subset of Common Lisp.
I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant. Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''
As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
be available in the first half of 1989 (Beta available in December).
He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting).
The convener declared that discussion on this topic was deadlocked
until AFNOR could meet to decide their response to the US and German
position statements, which would not be until after the Hawaii
meeting. However, the convener told Mathis in private that he did not
want to go to Hawaii and was trying to find a way to cancel the
meeting. The convener also threatened to report failure to SC22 based
on his opinion that a consensus is not possible.
The US delegation agreed to ask X3J13 and the IEEE Scheme groups
whether they were willing to submit drafts under the German proposal.
While so agreeing, we pointed out that the convener was acting as if
the German position would be accepted. I pointed out that the US had
not withdrawn its proposed resolution.
The US delegation repeatedly commented that the US position was
intended to support Common Lisp users and was not intended to prevent
other distinct standards from being established to serve other
communities.
I expect that the word from AFNOR to the European community will be
that the US deliberately tried to block the ISO process, though I'm
not sure what reason he will provide for the US actions.
The second day of the meeting was devoted to three presentations:
Gabriel presented a report on the progress that US Common Lisp vendors
had made in the area of delivery of applications written in Common
Lisp. Mr Kurokawa presented a report on Japanese activity on
provisions within Common Lisp for international character sets. Thom
Linden presented the latest X3J13 work on the same topic. In
addition, the U.S. was asked to present the current WG16 status on
character handling at the next SC22 meeting.
The next ISO meeting is in March in Fairfax, Virginia.
-rpg-
------- End undelivered message -------
∂29-Nov-88 1353 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1353 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:52:54 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 499492; Tue 29-Nov-88 16:52:55 EST
Date: Tue, 29 Nov 88 16:52 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881129165233.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Well, I've caved in to the EXPLICITLY-VAGUE camp due to changes in my
thinking over the past year on where it is appropriate to trade off
efficiency and portability. Anyway, guided by my newfound wisdom and
DLA's persistent view, I've stripped out my counter-proposal and
rearranged things a bit to make this neat and pretty. Hope this new
presentation doesn't raise too much uproar...
-kmp
-----
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE):
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
Current Practice:
All valid implementations are believed to comply.
Cost to Implementors:
None. This is the status quo for implementors.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre support this proposal.
------- End undelivered message -------
∂29-Nov-88 1418 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1418 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:13:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA26984; Tue, 29 Nov 88 15:10:03 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12266; Tue, 29 Nov 88 15:08:58 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811292208.AA12266@defun.utah.edu>
Date: Tue, 29 Nov 88 15:08:56 MST
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: Gray@DSG.csc.ti.com, cperdue@Sun.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: System Files <SYS@SAIL.Stanford.EDU>, 29 Nov 88 1256 PST
Do either of you have any specific thoughts on how to get around the
initialization problem, or do you think the problem is so
insurmountable that we should either drop this issue or take a
completely different approach on it?
As I suggested in my previous message, the solution I'd propose is
saying that it is not an error to SETQ an unbound variable that has
been proclaimed CONSTANT (it only becomes an error to SETQ it once it
has been initialized). What do the rest of you think of this?
-Sandra
-------
------- End undelivered message -------
∂29-Nov-88 1353 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG; cl@draper.com
Here is how the remote host(s) replied to these mail addresses:
delatizky@BBN.COM
451 Nameserver timeout during parsing
FWHITE@BBN.COM
451 Nameserver timeout during parsing
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 1353 Common-Lisp-mailer Re: Common Lisp for SUNS
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA24518; Tue, 29 Nov 88 13:52:04 PST
Received: from frisky by franz (3.2/3.14)
id AA24713; Tue, 29 Nov 88 13:43:03 PST
Received: by frisky (3.2/3.14)
id AA02600; Tue, 29 Nov 88 13:40:54 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8811292140.AA02600@frisky>
To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase)
Cc: franz!sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST.
<8811291614.AA01479@red.ipsa.dnd.ca>
Date: Tue, 29 Nov 88 13:40:53 PST
Regarding benchmarking Lisps.
1. Declarations are important for speed, but you'll find that some
Lisps will require more specific declarations than others.
For example Sun's Lisp only supports one floating point type so declaring
something to be a 'float' is sufficient for the compiler to open code
the operation. Allegro supports two types of floats so you must declare
either 'single-float' or 'double-float.'
2. Different systems do different amounts of optimizations based on
the settings of the optimization parameters speed, safety and size.
Probably the only comparable values are for speed=3, safety=0, size=0
where each system does maximum optimization. While benchmarks
run at this value are interesting you probably aren't going to
do development with these settings since you aren't going to get
good diagnostics.
Regarding the Lisp on the Sun4.
Allegro is highly optimized for the Sun4 but you have to
add some declarations and specify that speed is important.
The comment was made that a C based Lisp on the Sun4 would
be very fast because of sun's optimizing C compiler.
While it is true that by using C you can take advantage of that
compiler, it is also true that the use of C constrains your
whole system design so you can't use the machine optimally.
I say this from many years experience programming in C parts of the
kernel of Franz Lisp. To cite two examples for the Sun4:
One of the nicest features of the sun4 (sparc) architecture
is the support the the Lisp fixnum data type (there are 'tagged'
versions of the add, subtract and compare instructions).
This allows the compiler to open code +,-,<,<=.. and so on
and if the operands happen to be fixnums (they very often are)
then the operation and fixnum tag check can go on in parallel.
This makes for fast computation in the typical case
and it is completely safe (if the tags aren't fixnum you find out
about it and perform the appropriate operation for the
actual data types).
A C based lisp can't make use of these tagged instructions.
The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asychronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp.
[The use of machine registers to hold certain values was
so important in Franz Lisp that for certain regular
architectures (e.g. vax) an incredible hack was written
by Keith Sklower to modify the assembler language coming
out of the C compiler to change certain memory references
to register references and to fix the register save masks.]
-- John Foderaro
Franz Inc.
jkf%franz.uucp@berkeley.edu
------- End undelivered message -------
∂29-Nov-88 1502 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com
------- Begin undelivered message: -------
29-Nov-88 1502 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:01:45 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07164; 29 Nov 88 18:50 GMT
Date: Tue, 29 Nov 88 18:52:35 GMT
Message-Id: <14858.8811291852@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, CL-Compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Mon, 28 Nov 88 13:00 EST
On the whole, I prefer this, more conservative, approach.
> The target environment of code compiled by the COMPILE-FILE function
> may be very different than the environment in which the compilation
> occurred. As such, it is not generally possible to reliably preserve
> object identity or sharing (under EQL) of constants occurring in
> programs processed by COMPILE-FILE.
> Current practice:
> Cost to Imlementors:
We might want to remember that KCL represents a fairly large slice
of current use and that it doesn't do some of the things some of the
proposals suggest. KCL dumps constants by printing them. The dump/
load process doesn't do anything fancier than you can do with PRINT
and READ. And READ, like LOAD, may bring constants into a different
environment. There is also a long tradition that PRINT prints things
so they can be read back in (while PRINC, say, does not). So I am
uncomfortable with proposals that make dump/load and print/read very
different beasts.
> Cost to Users:
>
> Any serious portable code is probably already compatible with this
> proposal.
I'm not sure what "serious" is supposed to signify. What's the
difference between "serious protable code" and just "portable code"?
------- End undelivered message -------
∂29-Nov-88 1503 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com
------- Begin undelivered message: -------
29-Nov-88 1503 CL-Compiler-mailer Re: Objects in quoted constants
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:02:48 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07244; 29 Nov 88 19:11 GMT
Date: Tue, 29 Nov 88 19:13:16 GMT
Message-Id: <14929.8811291913@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Objects in quoted constants
To: "Robert W. Kerns" <RWK%f.ila.dialnet.symbolics.com@NSS.Cs.Ucl.AC.UK>,
Jon L White <@sail.stanford.edu:jonl@lucid.com>
In-Reply-To: Robert W. Kerns's message of Sun, 27 Nov 88 03:39 EST
Cc: cl-compiler@sail.stanford.edu, RWK@ai.ai.mit.edu, cperdue@sun.com
> I submit that we should make the choice to retain MORE information than
> doing PRINT/READ, but LESS information than doing
> DISK-SAVE-THE-ENTIRE-ADDRESS-SPACE.
Provided it's not a lot more than PRINT/READ, I agree.
> In fact, there *ARE* implementations which communicate their constants
> by PRINT/READ, so anything beyond what PRINT/READ convey *WILL BE A
> SIGNIFICANT BURDEN FOR THOSE LISPS*. It's not just FRANZ Lisp; KCL and
> its descendants seem to have caught the disease from FRANZ. (Lest
> anybody be confused, I'm not talking about Franz, Inc's product here,
> I'm talking about a pre-Common-Lisp done at UCB. There's a connection,
> but it's not relevant to this.)
Well, one might call it a disease, but I think it's an inconsistency
when dump/load and print/read are vastly different, and the inconsistency
might be resolved by moving dump/load in the direction of print/read.
BTW, the Berkeley Franz approach was less of a problem in Franz than
it is in Common Lisp, because there are no packages.
> The guiding principles I've used in making my choices are:
Well said.
-- Jeff
------- End undelivered message -------
∂29-Nov-88 1504 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com
------- Begin undelivered message: -------
29-Nov-88 1504 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:04:25 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07384; 29 Nov 88 19:31 GMT
Date: Tue, 29 Nov 88 19:33:05 GMT
Message-Id: <14986.8811291933@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra <@cs.utah.edu:sandra@defun>,
Kent M Pitman <KMP@scrc-stony-brook.arpa>
In-Reply-To: Sandra J Loosemore's message of Mon, 28 Nov 88 13:14:28 MST
Cc: CL-Compiler@sail.stanford.edu
> The only implementation I know of that implemented COMPILE using
> file compilation (KCL) apparently no longer does so.
My recollection is that KCL prints the data to a file but doesn't
print the code. It used to print the code, which caused problems
with gensyms and the like. But it still prints the constants to
a file and (when LOADing) reads them back in.
But it would be fairly easy to change KCL so that it no longer
printed or read the data.
-- Jeff
------- End undelivered message -------
∂29-Nov-88 1504 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; clcomp@draper.com
------- Begin undelivered message: -------
29-Nov-88 1504 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:03:27 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07292; 29 Nov 88 19:19 GMT
Date: Tue, 29 Nov 88 19:22:02 GMT
Message-Id: <14957.8811291922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra (Sandra J Loosemore) <@cs.utah.edu:sandra@defun>,
Kent M Pitman <KMP@NSS.Cs.Ucl.AC.UK>,
28 Nov 88 1314: "28 MST"@aiai.edinburgh.ac.uk;,
Cc: CL-Compiler@sail.stanford.edu;
MMDF-Warning: Parse error in original version of preceding line at .NSS.Cs.Ucl.AC.UK
> The only implementation I know of that implemented COMPILE using
> file compilation (KCL) apparently no longer does so.
My recollection is that KCL prints the data to a file but doesn't
print the code. It used to print the code, which caused problems
with gensyms and the like. But it still prints the constants to
a file and (when LOADing) reads them back in.
But it would be fairly easy to change KCL so that it no longer
printed or read the data.
-- Jeff
------- End undelivered message -------
∂29-Nov-88 1430 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host(s) replied to these mail addresses:
delatizky@BBN.COM
451 Nameserver timeout during parsing
FWHITE@BBN.COM
451 Nameserver timeout during parsing
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 1430 Common-Lisp-mailer inconsistency in backquote spec?
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST
Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST
Date: Tue, 29 Nov 88 17:12:40 EST
From: gls@Think.COM
Message-Id: <8811292212.AA00825@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com,
common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
...
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item would
invalidate the examples.
--Guy
------- End undelivered message -------
∂29-Nov-88 1603 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1603 CL-Cleanup-mailer Re: Issue: STREAM-CAPABILITIES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 16:03:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 29 NOV 88 15:50:15 PST
Date: 29 Nov 88 15:49 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-CAPABILITIES (Version 1)
In-reply-to: Dan L. Pierson <pierson@mist.ARPA>'s message of Wed, 16 Nov 88
16:25:38 EST
To: Dan L. Pierson <pierson@mist.ARPA>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881129-155015-6276@Xerox>
When Moon said
"I think adding something that cannot be correctly implemented will lead
to more rather than less portable code."
I thought I understood him and agreed. If you add a new feature to the
standard, people will use that feature. If the feature can't really be
implemented "correctly", and different implementors treat the feature
differently, users will write code that winds up depending on the
implementation-dependent interpretation of the standard.
I'm inclined to believe that we should decide what these mean in individual
operating systems, and then see if the concepts map into features that
could be operating-system independent. Trying to write the generic prose
without some specific examples is leading us into more ambiguous wording
rather than less.
I see no reason to separate the proposals here into separate issues. I
think these might well be lumped in with the "pathname" issues in a bigger
category of "standardizing file system interactions".
------- End undelivered message -------
∂29-Nov-88 1619 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1619 CL-Cleanup-mailer Re: Issue: STREAM-CAPABILITIES (Version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 16:19:34 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA12132; Tue, 29 Nov 88 19:17:41 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA00505; Tue, 29 Nov 88 19:17:51 EST
Message-Id: <8811300017.AA00505@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: STREAM-CAPABILITIES (Version 1)
In-Reply-To: Your message of 29 Nov 88 15:49:00 -0800.
<881129-155015-6276@Xerox>
Date: Tue, 29 Nov 88 19:17:49 EST
From: Dan L. Pierson <pierson@mist.encore.com>
(I'm back on the net after a week and a half of local network reconfigurations)
When Moon said
"I think adding something that cannot be correctly implemented will lead
to more rather than less portable code."
I thought I understood him and agreed. If you add a new feature to the
standard, people will use that feature. If the feature can't really be
implemented "correctly", and different implementors treat the feature
differently, users will write code that winds up depending on the
implementation-dependent interpretation of the standard.
I agree with you but I think Moon's wording (but probably not
thinking) says the exact opposite. If more portable code is agreed to
be a good thing, he seems to be saying that adding features which
can't be correctly implemented will lead to this good result....
I'm inclined to believe that we should decide what these mean in individual
operating systems, and then see if the concepts map into features that
could be operating-system independent. Trying to write the generic prose
without some specific examples is leading us into more ambiguous wording
rather than less.
You're getting more convincing every time you say this. I've really
got to try and get a survey together.
I see no reason to separate the proposals here into separate issues. I
think these might well be lumped in with the "pathname" issues in a bigger
category of "standardizing file system interactions".
OK, I'll just let the current draft sit for now.
------- End undelivered message -------
∂29-Nov-88 1737 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1737 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 17:37:12 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02327g; Tue, 29 Nov 88 17:34:24 PST
Received: by bhopal id AA02796g; Tue, 29 Nov 88 17:31:48 PST
Date: Tue, 29 Nov 88 17:31:48 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811300131.AA02796@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 29 Nov 88 12:19 EST <19881129171957.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
re: The package value is one of the packages present or named in the
<package-list> argument. The meaning of the second, third, and fourth
values is that the returned symbol is accessible in the returned package
in the specified way: present and not exported if :INTERNAL, present
and exported if :EXTERNAL, or not present and inherited from some other
package and not shadowed if :INHERITED.
This paragraph looks fine. If not one else has comments, the either you
or I should emmed the final version accordingly; also don't forget
to swap the (3) and (4) items for return value.
-- JonL --
------- End undelivered message -------
∂29-Nov-88 1806 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1806 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 18:06:11 PST
Received: by ti.com id AA18353; Tue, 29 Nov 88 20:03:47 CST
Received: from Kelvin by tilde id AA04456; Tue, 29 Nov 88 19:47:40 CST
Message-Id: <2805846591-11974684@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 29 Nov 88 19:49:51 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
In-Reply-To: Msg of Tue, 29 Nov 88 15:08:56 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Do either of you have any specific thoughts on how to get around the
> initialization problem,
The options appear to be to either revert back to version 4 or version 1,
neither of which had this problem.
> As I suggested in my previous message, the solution I'd propose is
> saying that it is not an error to SETQ an unbound variable that has
> been proclaimed CONSTANT (it only becomes an error to SETQ it once it
> has been initialized).
This still doesn't solve the problem of re-loading the file.
------- End undelivered message -------
∂29-Nov-88 1840 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1840 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 18:39:15 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA06401; Tue, 29 Nov 88 19:36:03 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12495; Tue, 29 Nov 88 19:34:59 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811300234.AA12495@defun.utah.edu>
Date: Tue, 29 Nov 88 19:34:58 MST
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore), cperdue@Sun.COM,
cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Tue, 29 Nov 88 19:49:51 CST
> Date: Tue, 29 Nov 88 19:49:51 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> The options appear to be to either revert back to version 4 or version 1,
> neither of which had this problem.
But version 4 had another problem -- it implicitly assumed that
switching a variable back and forth between SPECIAL and CONSTANT was
acceptable style. CLtL is unambiguous that references to undeclared
free variables are to be treated as references to its special binding,
yet many implementations issue warnings about doing so as a matter of
style. I claim that it is just as acceptable for an implementation to
issue a style warning about changing a DEFVAR to a DEFCONSTANT or vice
versa.
> This still doesn't solve the problem of re-loading the file.
Not directly. On the other hand, it does allow you to do something like:
(defmacro defconst (variable value)
`(progn
(eval-when (eval compile load)
(proclaim '(constant ,variable)))
(makunbound ',variable)
(setq ,variable ,value)
',variable))
(defconst memory-size (determine-memory-size))
Basically, we have to decide whether we want to add a macro like
DEFCONST (or DEFPARAMETER-UNALTERABLE, or whatever we want to call it)
to the language, or to make the hook it uses available directly, or
both, or neither. The main arguments for having a CONSTANT
declaration are that it makes the hook that DEFCONSTANT already uses
visible, and it also allows for lexically scoped constants. On the
other hand, it is somewhat more awkward to use correctly than a canned
defining macro.
-Sandra
-------
------- End undelivered message -------
∂29-Nov-88 1930 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1930 CL-Compiler-mailer issue DEFCONSTANT-NOT-WIRED, version 5
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 19:30:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02377g; Tue, 29 Nov 88 19:28:05 PST
Received: by bhopal id AA02975g; Tue, 29 Nov 88 19:26:58 PST
Date: Tue, 29 Nov 88 19:26:58 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8811300326.AA02975@bhopal>
To: sandra%defun@cs.utah.edu
Cc: Gray@DSG.csc.ti.com, sandra%defun@cs.utah.edu, cperdue@Sun.COM,
cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 29 Nov 88 19:34:58 MST <8811300234.AA12495@defun.utah.edu>
Subject: issue DEFCONSTANT-NOT-WIRED, version 5
To extend your example, what about something like:
(defmacro defconst (variable value)
`(progn
(eval-when (eval compile load)
(proclaim '(constant ,variable)))
(let ((new-value ,value))
(unless (equal ,variable new-value)
(warn "The constant ~S is being reset from ~S to ~S"
',variable
,variable
new-value)
(makunbound ',variable)
(setq ,variable new-value)
',variable))))
(defconst memory-size (determine-memory-size))
This has the advantage that reloading a file with a defconst in it
will have the nice property of usually not changing the constant
(i.e., EQ-ness is preserved). When the constant does change, a
warning is issued.
The disadvantage is that this makes rather ad hoc use of EQUAL,
but maybe that's not so bad--the behavior is simple and predictable,
and users can roll their own variant of defconst if this one isn't
what they want...
jlm
------- End undelivered message -------
∂29-Nov-88 1937 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 1937 CL-Cleanup-mailer Issue: SETF-PLACES (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 19:37:04 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02387g; Tue, 29 Nov 88 19:35:00 PST
Received: by bhopal id AA02997g; Tue, 29 Nov 88 19:33:53 PST
Date: Tue, 29 Nov 88 19:33:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811300333.AA02997@bhopal>
To: Gray@DSG.csc.ti.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Tue, 29 Nov 88 11:15:33 CST <2805815733-10120696@Kelvin>
Subject: Issue: SETF-PLACES (version 1)
re: But if you are going extend the lowest level primitives, FBOUNDP and
SYMBOL-FUNCTION, to accept function specs, then I don't see that you
gain very much by saying that higher-level macros and special forms
won't accept them. ....
That is not the proposal. In fact it is to _retract_ the CLOS imposed
requirement that every implementation's version of FBOUNDP and
SYMBOL-FUNCTION has to accept function specs. Only implementations
which already allow DEFUN etc to admit functions specs will have to
change their FBOUNDP and SYMBOL-FUNCTION accordingly; this would be true
regardless of whether we accept SETF-FUNCTION-VS-MACRO or SETF-PLACES.
If the intent is to limit the amount of change to implementations that
don't already support function specs, it seems like it would be easier
to leave FBOUNDP and SYMBOL-FUNCTION alone, introduce FDEFINEDP and
FDEFINITION, and then say that DEFMETHOD, DEFGENERIC, etc. use
FDEFINITION instead of SYMBOL-FUNCTION.
I considered that, and rather liked it, but didn't find much support for
it amongst others (Patrick was, I think, the main opponent; but I don't
think Gregor liked it either). Either way, we would have to change the
CLOS spec. In one case [the setf-places proposal] we would have to replace
(FBOUNDP ...) in the CLOS spec by (FBOUNDP (UNDERLYING- ...)), etc., and in
the other case we would have to to [1] Add new functions FDEFINEDP and
FDEFINITION, and [2] replace (FBOUNDP ...) in the CLOS spec by
(FDEFINEDP ...) etc.
re: The next question is whether there is really a
need for the user to know about UNDERLYING-NAME. The only use I can
think of would be to do a GET on the underlying symbol, or to use it as
a key in an EQ hash table, but neither of those would be portable since
UNDERLYING-NAME could return a non-symbol on some implementations.
I don't forsee any reasonable portable use of UNDERLYING-NAME for the
end user; its existence is primarily to expose the barrier between the
surface syntax of setf generic functions and the implementation-specific
way in which hooks into function definition. The end user will be using
CLOS primitives. UNDERLYING-NAME is aimed at sub-system implementors,
especially at the PCL implementor/maintainer, so that his code can be
portable. But since any implmentation that doesn't support true
functions specs will have to have some such mapping (the "underlying"
name), it might as well be a standardized function to access it.
re: > Looking ahead, I see that several more of the "Brothers-..." have
> made the same request, which basically boils down to requiring all
> implementations to have the essence of function specs by "trojan horse".
But I've just shown you how to implement the essence of function specs
in only eleven lines of code. Well, make that thirteen because you
probably want this too:
With all due respect David, you've shown how to implement function specs
for DEFUN. The original SETF-FUNCTION-VS-MACRO listed 18 Common Lisp
constructs that would have to be changed, and that doesn't count the
pain for the several portable code-walkers running around. DEFUN is the
easy one, because it generally is just a macro (as DEFMETHOD is a macro).
At any rate, the killer objection is not how much or how little work it is
to implement function specs, but rather that there is still an enormous
undercurrent of distaste for list-as-function-names.
re: But if you accept lists to name functions in certain contexts, how does
it really help to say that they aren't "function specs"? Since I'm
obviously coming from a very biased perspective, I don't see anything
un-esthetic about using lists as function names. It's certainly a
concept that has been around a long time and has proven very useful.
To say that the way you incrementally define the setf method for a
generic function is by use of a form like (DEFMETHOD (SETF foo) ...)
is not by itself acceptance of lists-as-names. One can pretend that
this is just a macro that expands into (DEFUN SOME-SYMBOL ...)
[along with whatever implementation-dependent processing is needed to
distinguish generic functions from regular ones]. The difficulty
arises when you require something like (SYMBOL-FUNCTION '(SETF foo))
to have meaning; for those implementations without function specs,
this is the uncrossable barrier. The current setf-places proposal
neatly puts in the little "fence" by saying:
(SYMBOL-FUNCTION (UNDERLYING-NAME '(SETF foo)))
An implementation that already has function specs isn't affected at
all by this, since it is permitted to define UNDERLYING-NAME as the
identity function.
-- JonL --
------- End undelivered message -------
∂29-Nov-88 2048 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:48:02 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA06867; Tue, 29 Nov 88 23:47:10 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 00:58:11 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB24031 (5.52.1.1/2.14); Wed, 30 Nov 88 00:52:22 +0100 (MET)
Message-Id: <8811292356.AB24031@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 00:52:22 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA24031 (5.52.1.1/2.14); Wed, 30 Nov 88 00:56:43 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 00:52:22 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA04462; Tue, 29 Nov 88 14:59:25 EST
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <mcvax!STONY-BROOK.SCRC.Symbolics.COM!Greenwald>
Subject: inconsistency in backquote spec?
To: Think.COM!gls, STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.edu!common-lisp
In-Reply-To: <8811291735.AA00711@joplin.think.com>
Message-Id: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Or, you could say that the list following a ,@ cannot be dotted.
Either way, I think, requires a minor clarification in the CL spec.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
∂29-Nov-88 2048 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:48:33 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA06933; Tue, 29 Nov 88 23:47:45 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 01:01:55 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB24213 (5.52.1.1/2.14); Wed, 30 Nov 88 00:49:24 +0100 (MET)
Message-Id: <8811300000.AB24213@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 00:49:24 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA24213 (5.52.1.1/2.14); Wed, 30 Nov 88 01:00:31 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 00:49:24 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA03479; Tue, 29 Nov 88 14:49:32 EST
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST
Received: by tut.cis.ohio-state.edu (5.59/2.881128)
id AA25824; Tue, 29 Nov 88 14:12:36 EST
Date: Tue, 29 Nov 88 14:12:36 EST
From: Arun Welch <mcvax!cis.ohio-state.edu!welch>
Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu>
To: think.com!barmar
Cc: sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
>
>Kyoto CL is not generally considered a high-performance Lisp. Its major
>feature is its portability, since it is written mostly in C and its
>compiler uses C as the intermediate language. It is also well-known for
>being very faithful to CLtL, implementing all and only what the book
>says.
We're in the process of coming up with a decision on what lisp to get
for the University, and have been looking at Ibuki, Franz, and Envos
(and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has
been benchmarking them on Sun-3's and Sun-4's, and we've noticed that
in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind
of amazed by this, until we realised that Ibuki uses the native C
compiler, which is optimising for the SPARC architecture on the -4,
while none of the others were. This wasn't an across-the-board
speedup, just for some of the things we tried. I'd pretty much agree
with your other assessment of Kyoto CL, modulo the fact that Ibuki has
extended it somewhat (folding in the new error system, for example).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
∂29-Nov-88 2050 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:50:22 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA07090; Tue, 29 Nov 88 23:49:33 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 00:41:16 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB23177 (5.52.1.1/2.14); Wed, 30 Nov 88 00:29:06 +0100 (MET)
Message-Id: <8811292339.AB23177@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 00:29:06 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA23177 (5.52.1.1/2.14); Wed, 30 Nov 88 00:39:19 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 00:29:06 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA29087; Tue, 29 Nov 88 14:13:01 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST
Date: Tue, 29 Nov 88 13:55 EST
From: Michael Greenwald <mcvax!STONY-BROOK.SCRC.Symbolics.COM!Greenwald>
Subject: inconsistency in backquote spec?
To: lucid.com!jonl, STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.edu!common-lisp
In-Reply-To: <8811290810.AA00624@bhopal>
Message-Id: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I agree with this (I think there's a CL cleanup that specifies this
behavior for APPEND and NCONC), and therefore the Lucid backquote
implementation is inconsistent with the definition of APPEND.
(setq d '(a . b))
`(,@d)
`(,@d . nil)
(append [,@d] 'nil)
(append d 'nil)
(append '(a . b) 'nil)
should be (a), as in your example above.
However, it was (a . b) on the version I tried - I didn't try the APPEND
case itself, so maybe in a later version both were made consistent.
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂29-Nov-88 2053 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 2053 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:53:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 499774; Tue 29-Nov-88 23:52:41 EST
Date: Tue, 29 Nov 88 23:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811300131.AA02796@bhopal>
Message-ID: <19881130045224.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 17:31:48 PST
From: Jon L White <jonl@lucid.com>
re: The package value is one of the packages present or named in the
<package-list> argument. The meaning of the second, third, and fourth
values is that the returned symbol is accessible in the returned package
in the specified way: present and not exported if :INTERNAL, present
and exported if :EXTERNAL, or not present and inherited from some other
package and not shadowed if :INHERITED.
This paragraph looks fine. If not one else has comments, the either you
or I should emmed the final version accordingly; also don't forget
to swap the (3) and (4) items for return value.
Could you do it? I'm not going to be able to do any more Common Lisp work
until after December 7. Maybe I'll read the mail, maybe I won't.
------- End undelivered message -------
∂29-Nov-88 2104 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:03:58 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA08727; Wed, 30 Nov 88 00:03:02 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 01:54:49 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB24907 (5.52.1.1/2.14); Wed, 30 Nov 88 01:51:30 +0100 (MET)
Message-Id: <8811300053.AB24907@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 01:51:30 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA24907 (5.52.1.1/2.14); Wed, 30 Nov 88 01:53:28 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 01:51:30 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA28297; Tue, 29 Nov 88 17:57:39 EST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST
Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST
Date: Tue, 29 Nov 88 17:12:40 EST
From: mcvax!Think.COM!gls
Message-Id: <8811292212.AA00825@joplin.think.com>
To: stony-brook.scrc.symbolics.com!Greenwald
Cc: Think.COM!gls, stony-brook.scrc.symbolics.com!Greenwald,
sail.stanford.edu!common-lisp
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
...
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item would
invalidate the examples.
--Guy
∂29-Nov-88 2114 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:14:24 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00791; Tue, 29 Nov 88 21:13:15 PST
Date: Tue, 29 Nov 88 21:13:15 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300513.AA00791@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00781; Tue, 29 Nov 88 21:13:15 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA01882; Tue, 29 Nov 88 21:13:00 PST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>, common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
∂29-Nov-88 2122 Mailer@MCC.COM Message of 29-Nov-88 23:20:48
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:21:47 PST
Date: Tue 29 Nov 88 23:20:55-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 29-Nov-88 23:20:48
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 29 Nov 88 23:20:50-CST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>, common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
-------
∂29-Nov-88 2057 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; bbd-common-lisp@aic.nrl.navy.mil; coffee@AEROSPACE.AERO.ORG; beer@cwcais.cwru.edu
------- Begin undelivered message: -------
29-Nov-88 2057 Common-Lisp-mailer Common Lisp for SUNS
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>, common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
------- End undelivered message -------
∂29-Nov-88 2148 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:48:16 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01626; Tue, 29 Nov 88 21:45:52 PST
Date: Tue, 29 Nov 88 21:45:52 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300545.AA01626@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01575; Tue, 29 Nov 88 21:45:52 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA25636; Tue, 29 Nov 88 14:46:26 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST
Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST
Date: Tue, 29 Nov 88 17:12:40 EST
From: gls@Think.COM
Message-Id: <8811292212.AA00825@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com,
common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
...
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item would
invalidate the examples.
--Guy
∂29-Nov-88 2150 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:50:50 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01682; Tue, 29 Nov 88 21:49:53 PST
Date: Tue, 29 Nov 88 21:49:53 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300549.AA01682@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01680; Tue, 29 Nov 88 21:49:53 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA25024; Tue, 29 Nov 88 14:17:50 PST
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA24518; Tue, 29 Nov 88 13:52:04 PST
Received: from frisky by franz (3.2/3.14)
id AA24713; Tue, 29 Nov 88 13:43:03 PST
Received: by frisky (3.2/3.14)
id AA02600; Tue, 29 Nov 88 13:40:54 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8811292140.AA02600@frisky>
To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase)
Cc: franz!sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST.
<8811291614.AA01479@red.ipsa.dnd.ca>
Date: Tue, 29 Nov 88 13:40:53 PST
Regarding benchmarking Lisps.
1. Declarations are important for speed, but you'll find that some
Lisps will require more specific declarations than others.
For example Sun's Lisp only supports one floating point type so declaring
something to be a 'float' is sufficient for the compiler to open code
the operation. Allegro supports two types of floats so you must declare
either 'single-float' or 'double-float.'
2. Different systems do different amounts of optimizations based on
the settings of the optimization parameters speed, safety and size.
Probably the only comparable values are for speed=3, safety=0, size=0
where each system does maximum optimization. While benchmarks
run at this value are interesting you probably aren't going to
do development with these settings since you aren't going to get
good diagnostics.
Regarding the Lisp on the Sun4.
Allegro is highly optimized for the Sun4 but you have to
add some declarations and specify that speed is important.
The comment was made that a C based Lisp on the Sun4 would
be very fast because of sun's optimizing C compiler.
While it is true that by using C you can take advantage of that
compiler, it is also true that the use of C constrains your
whole system design so you can't use the machine optimally.
I say this from many years experience programming in C parts of the
kernel of Franz Lisp. To cite two examples for the Sun4:
One of the nicest features of the sun4 (sparc) architecture
is the support the the Lisp fixnum data type (there are 'tagged'
versions of the add, subtract and compare instructions).
This allows the compiler to open code +,-,<,<=.. and so on
and if the operands happen to be fixnums (they very often are)
then the operation and fixnum tag check can go on in parallel.
This makes for fast computation in the typical case
and it is completely safe (if the tags aren't fixnum you find out
about it and perform the appropriate operation for the
actual data types).
A C based lisp can't make use of these tagged instructions.
The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asychronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp.
[The use of machine registers to hold certain values was
so important in Franz Lisp that for certain regular
architectures (e.g. vax) an incredible hack was written
by Keith Sklower to modify the assembler language coming
out of the C compiler to change certain memory references
to register references and to fix the register save masks.]
-- John Foderaro
Franz Inc.
jkf%franz.uucp@berkeley.edu
∂29-Nov-88 2151 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:51:49 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01693; Tue, 29 Nov 88 21:49:58 PST
Date: Tue, 29 Nov 88 21:49:58 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300549.AA01693@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01687; Tue, 29 Nov 88 21:49:58 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA22970; Tue, 29 Nov 88 11:49:34 PST
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: gls@Think.COM, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291735.AA00711@joplin.think.com>
Message-Id: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Or, you could say that the list following a ,@ cannot be dotted.
Either way, I think, requires a minor clarification in the CL spec.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
∂29-Nov-88 2155 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:55:28 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01798; Tue, 29 Nov 88 21:53:40 PST
Date: Tue, 29 Nov 88 21:53:40 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300553.AA01798@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01759; Tue, 29 Nov 88 21:53:40 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA22179; Tue, 29 Nov 88 11:03:16 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST
Date: Tue, 29 Nov 88 13:55 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: jonl@lucid.com, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811290810.AA00624@bhopal>
Message-Id: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I agree with this (I think there's a CL cleanup that specifies this
behavior for APPEND and NCONC), and therefore the Lucid backquote
implementation is inconsistent with the definition of APPEND.
(setq d '(a . b))
`(,@d)
`(,@d . nil)
(append [,@d] 'nil)
(append d 'nil)
(append '(a . b) 'nil)
should be (a), as in your example above.
However, it was (a . b) on the version I tried - I didn't try the APPEND
case itself, so maybe in a later version both were made consistent.
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂29-Nov-88 2157 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:56:23 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01827; Tue, 29 Nov 88 21:54:35 PST
Date: Tue, 29 Nov 88 21:54:35 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300554.AA01827@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01807; Tue, 29 Nov 88 21:54:35 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA22784; Tue, 29 Nov 88 11:39:37 PST
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST
Received: by tut.cis.ohio-state.edu (5.59/2.881128)
id AA25824; Tue, 29 Nov 88 14:12:36 EST
Date: Tue, 29 Nov 88 14:12:36 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu>
To: barmar@think.com
Cc: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
>
>Kyoto CL is not generally considered a high-performance Lisp. Its major
>feature is its portability, since it is written mostly in C and its
>compiler uses C as the intermediate language. It is also well-known for
>being very faithful to CLtL, implementing all and only what the book
>says.
We're in the process of coming up with a decision on what lisp to get
for the University, and have been looking at Ibuki, Franz, and Envos
(and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has
been benchmarking them on Sun-3's and Sun-4's, and we've noticed that
in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind
of amazed by this, until we realised that Ibuki uses the native C
compiler, which is optimising for the SPARC architecture on the -4,
while none of the others were. This wasn't an across-the-board
speedup, just for some of the things we tried. I'd pretty much agree
with your other assessment of Kyoto CL, modulo the fact that Ibuki has
extended it somewhat (folding in the new error system, for example).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
∂29-Nov-88 2159 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:59:46 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01881; Tue, 29 Nov 88 21:58:10 PST
Date: Tue, 29 Nov 88 21:58:10 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300558.AA01881@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA01858; Tue, 29 Nov 88 21:58:10 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA21962; Tue, 29 Nov 88 10:49:23 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST
Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 29 Nov 88 10:23:29 PST (Tuesday)
Subject: Re: inconsistency in backquote spec?
From: "Larry_Masinter.PARC"@Xerox.COM
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.EDU
In-Reply-To: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28
Nov 88 18:12
Message-Id: <881129-102742-5383@Xerox>
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
Status: PASSED
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
∂29-Nov-88 2221 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 2221 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 22:21:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02461g; Tue, 29 Nov 88 22:19:06 PST
Received: by bhopal id AA03229g; Tue, 29 Nov 88 22:17:59 PST
Date: Tue, 29 Nov 88 22:17:59 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811300617.AA03229@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 29 Nov 88 16:52 EST <881129165233.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
I'm not sure whether I care one way or the other about this issue (of
course, since DLA cares strongly, and I don't care, then that actually
biases me _towards_ the proposal).
However, there is one persistent problem in dealing with Lisp users
that I'd like to see ameliorated somewhat. This can be simply an
editorial point maybe, but I'd like to see a section in the spec
that concerns these "destructive" operations to say explicity that
it is perfectly all right for them _not_ to destroy anything but
instead to "cons" new results. A typical part of your proposal is:
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
Unbelievable as it may sound, 3 out of 4 end user will read that
statemtent and understand it to mean that it _must_ "SETF the parts",
and will complain when it doesn't. In particular, Lucid Common Lisp
will copy a vector rather than destructively update it unless it
is at least adjustable or fill-pointer'd (or both - can't remember
whether adjustablility is required). We can't adjust simple arrays,
and that means we can't adjust their length; so simply "sliding
things down" is not enough to effect the deletion. [please, no
beats upon the dead horse of all arrays being ....]
In fact, the opening words of your proposal would bias the casual
reader into thinking that the "destructive" option is required; it
reads as
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
...
How about adding the two-word subordinate clause as follows:
Clarify that the way in which the destructive behavior, if any, of the
operators below is achieved is explicitly vague in a number of ways,
...
??
A paragraph re-iterating the obvious may also be required.
-- JonL --
------- End undelivered message -------
∂29-Nov-88 2237 Mailer failed mail returned
To: Common-Lisp-mailer
The following message was undeliverable to recipient(s):
common-lisp@gmdzi.uucp@UUNET.UU.NET
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
29-Nov-88 2057 Common-Lisp-mailer Common Lisp for SUNS
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>, common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
------- End undelivered message -------
∂29-Nov-88 2247 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
29-Nov-88 2247 CL-Compiler-mailer Objects in quoted constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 22:47:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02486g; Tue, 29 Nov 88 22:44:58 PST
Received: by bhopal id AA03268g; Tue, 29 Nov 88 22:43:50 PST
Date: Tue, 29 Nov 88 22:43:50 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811300643.AA03268@bhopal>
To: RWK@F.ILA.Dialnet.Symbolics.COM
In-Reply-To: your msg of Mon, 28 Nov 88 21:21 EST
Subject: Objects in quoted constants
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
re: I've probably said enough on this, though, so I'll just observe that
PRINT/READ definitely do NOT preserve the EXISTENCE of the fill pointer.
Quite true. But does one bad bug deserve another? Some of us (myself
included) have been carping about the broken state of array printing
since 1985. Virtually all non-simple arrays lose badly; and even
simple arrays lose the upgraded-array-element-type information. Foo.
Jim MacDonald was going to submit a point of view that claims the
PRINT/READ scenario is _not_ an appropriate model for dump/load,
but rather the guideing principle should be preservation of at least
the components that the "MAKE" function has as arguments. Thus
Hash-Tables would have to preserve :test, :size, :rehash-size and
:rehash-threshold (in addition to the "contents"). This is especially
important when you remember that READ is not the only way to
create programs in Common Lisp -- remember the hairy macro-produced
specials that even you (yes, you Bob Kerns) used to write?
PRINT/READ preservation is appropriate for C-like languages;
Constructor-function argument preservation is appropriate for Lisp.
-- JonL --
------- End undelivered message -------
∂29-Nov-88 2325 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:25:37 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03575; Tue, 29 Nov 88 23:24:29 PST
Date: Tue, 29 Nov 88 23:24:29 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300724.AA03575@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03570; Tue, 29 Nov 88 23:24:29 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA21542; Tue, 29 Nov 88 10:22:43 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:09:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01681g; Tue, 29 Nov 88 10:06:59 PST
Received: by bhopal id AA01309g; Tue, 29 Nov 88 10:05:50 PST
Date: Tue, 29 Nov 88 10:05:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8811291805.AA01309@bhopal>
To: bill@red.ipsa.dnd.ca
In-Reply-To: Bill Pase's message of Tue, 29 Nov 88 11:14:29 EST <8811291614.AA01479@red.ipsa.dnd.ca>
Subject: Common Lisp for SUNS
Cc: common-lisp@sail.stanford.edu
I'm not the right person to send you benchmark data on Lucid Common
Lisp, but I thought I should mention that Sun Common Lisp is Lucid
Common Lisp. (Lucid makes it, Sun sells it.)
Also, I can give some general advice about benchmarks:
(1) Be sure to note the releases being compared. For example, LCL
Version 3.0 is significantly different from LCL Version 2.1. We
added a second compiler, an ephemeral garbage collector,
multi-tasking, better inline floating point code, new interrupts,
new I/O, etc., etc.
(2) Be sure that the person who produced the benchmark values
understands the benchmarks and the lisp being tested. Proper use
of declarations and compiler settings can sometimes produce
order-of-magnitude differences. Also, for example, the use of a
feature such as ephemeral garbage collection may reflect a
decision to accept a somewhat increased running time in order to
avoid detectable pauses for GC. Turning EGC off may result in
different (usually faster) benchmark values, and might or might
not be appropriate for various applications. You need to
understand how you're going to use the lisp to know what settings
are appropriate.
(3) Ask for the *precise* techniques used to obtain the benchmarks,
including processor speed, memory size, load on the machine, etc.
I know that some of the people at Lucid have produced benchmark
figures using what we call the "low-mode" -- we run each
benchmark about 20 times or more, then use some statistics to
produce a number one could expect to be the low value obtained
in a typical set of about 3 runs. (We didn't want to just
scrounge for the lowest value, since that's not always
reproducible, yet did want to give a fair indication of the
performance possible.) I'm pretty sure the techniques used are
distributed with the benchmark numbers.
(4) If performance is critical, explain this to the vendor. For
example, Lucid is now productizing tools to reorganize your code
based on an analysis of its dynamic performance, since code and
data locality can have order-of-magnitude affects on real-life
applications. Remember that you are going to be running
applications day-to-day, and not just benchmarks. Support in
this area can be as crucial as the underlying speed of the lisp!
Happy hunting,
jlm
∂29-Nov-88 2326 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:26:38 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03632; Tue, 29 Nov 88 23:24:46 PST
Date: Tue, 29 Nov 88 23:24:46 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300724.AA03632@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03582; Tue, 29 Nov 88 23:24:46 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA21099; Tue, 29 Nov 88 09:47:50 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:59 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 12:34:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 12:35:41 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 12:34:10 EST
Received: by joplin.think.com; Tue, 29 Nov 88 12:35:36 EST
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Message-Id: <8811291735.AA00711@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
∂29-Nov-88 2328 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:28:06 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03697; Tue, 29 Nov 88 23:27:03 PST
Date: Tue, 29 Nov 88 23:27:03 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300727.AA03697@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03692; Tue, 29 Nov 88 23:27:03 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA20625; Tue, 29 Nov 88 09:17:33 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:04:27 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 29 Nov 88 12:02:03 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 29 Nov 88 12:02:57 EST
Date: Tue, 29 Nov 88 12:03 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881129170307.7.BARMAR@OCCAM.THINK.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
Sun Common Lisp currently is Lucid Common Lisp. There were rumors last
year that they would be switching to Franz (who makes Allegro CL), but
this doesn't appear to have happened.
Kyoto CL is not generally considered a high-performance Lisp. Its major
feature is its portability, since it is written mostly in C and its
compiler uses C as the intermediate language. It is also well-known for
being very faithful to CLtL, implementing all and only what the book
says.
barmar
∂29-Nov-88 2328 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:28:18 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03708; Tue, 29 Nov 88 23:27:14 PST
Date: Tue, 29 Nov 88 23:27:14 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811300727.AA03708@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA03702; Tue, 29 Nov 88 23:27:14 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA19927; Tue, 29 Nov 88 08:28:39 PST
Received: from red.ipsa.dnd.ca by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:13:45 PST
Received: by red.ipsa.dnd.ca; (5.54/4.7)
id AA01479; Tue, 29 Nov 88 11:14:29 EST
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Message-Id: <8811291614.AA01479@red.ipsa.dnd.ca>
To: common-lisp@sail.stanford.edu
Subject: Common Lisp for SUNS
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
∂29-Nov-88 2338 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:37:59 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA04069; Tue, 29 Nov 88 23:37:08 PST
Received: by franz (3.2/3.14)
id AA25876; Tue, 29 Nov 88 23:29:30 PST
Date: Tue, 29 Nov 88 23:29:30 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8811300729.AA25876@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!CL-Compiler-mailer
----- Transcript of session follows -----
uux failed. code -1
554 feast!smh... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA25873; Tue, 29 Nov 88 23:29:30 PST
Received: from ucbvax.Berkeley.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA02173; Tue, 29 Nov 88 21:23:50 PST
Received: from Sail.Stanford.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00961; Tue, 29 Nov 88 21:23:41 PST
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:24 PST
Received: by ti.com id AA15345; Tue, 29 Nov 88 11:34:48 CST
Received: from Kelvin by tilde id AA25085; Tue, 29 Nov 88 11:28:10 CST
Message-Id: <2805816627-10174414@Kelvin>
Sender: ucbarpa!Kelvin.csc.ti.com!GRAY
Date: Tue, 29 Nov 88 11:30:27 CST
From: David N Gray <ucbarpa!DSG.csc.ti.com!Gray>
To: cs.utah.edu!sandra%defun (Sandra J Loosemore)
Cc: sail.stanford.edu!cl-compiler
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
In-Reply-To: Msg of Tue, 29 Nov 88 09:33:41 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Your solution of temporarily proclaiming the variable SPECIAL might
> suppress the SETQ'ing warning in some implementations, but I think it
> would also be just as appropriate for a compiler to emit a warning
> message when a variable is changed from CONSTANT to SPECIAL or vice
> versa, so it might lose in other implementations.
Such a warning would not be appropriate if we decide that that is the
way to initialize a constant. The only alternative I see is to go back
to the idea of having a new macro analogous to DEFPARAMETER for both
declaring and initializing not-wired constants.
∂29-Nov-88 2338 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:38:13 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA04075; Tue, 29 Nov 88 23:37:21 PST
Received: by franz (3.2/3.14)
id AA25862; Tue, 29 Nov 88 23:29:02 PST
Date: Tue, 29 Nov 88 23:29:02 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8811300729.AA25862@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!CL-Compiler-mailer
----- Transcript of session follows -----
uux failed. code -1
554 feast!smh... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA25860; Tue, 29 Nov 88 23:29:02 PST
Received: from ucbvax.Berkeley.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA02171; Tue, 29 Nov 88 21:23:47 PST
Received: from Sail.Stanford.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00958; Tue, 29 Nov 88 21:23:38 PST
Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:34:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA14125; Tue, 29 Nov 88 09:33:46 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12029; Tue, 29 Nov 88 09:33:42 MST
From: ucbarpa!cs.utah.edu!sandra%defun (Sandra J Loosemore)
Message-Id: <8811291633.AA12029@defun.utah.edu>
Date: Tue, 29 Nov 88 09:33:41 MST
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: David N Gray <DSG.csc.ti.com!Gray>
Cc: cs.utah.edu!sandra%defun (Sandra J Loosemore),
sail.stanford.edu!cl-compiler
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Tue, 29 Nov 88 09:17:18 CST
Actually, the same problems occurred to me while I was editing the
writeup. One solution that occurs to me is to put the PROCLAIM
CONSTANT -before- the SETQ, and say that it is not an error to SETQ a
variable that has been proclaimed CONSTANT but is unbound (that is,
hasn't been initialized yet). That still doesn't entirely address the
problem of reloading files, but at least it would provide a mechanism
so that DEFCONSTANT would be able to make redefining constants work.
(I thought putting this in would go beyond a mere editorial change,
which is why I didn't.)
Your solution of temporarily proclaiming the variable SPECIAL might
suppress the SETQ'ing warning in some implementations, but I think it
would also be just as appropriate for a compiler to emit a warning
message when a variable is changed from CONSTANT to SPECIAL or vice
versa, so it might lose in other implementations.
-Sandra
-------
∂29-Nov-88 2338 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:38:19 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA04089; Tue, 29 Nov 88 23:37:30 PST
Received: by franz (3.2/3.14)
id AA25821; Tue, 29 Nov 88 23:27:22 PST
Date: Tue, 29 Nov 88 23:27:22 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8811300727.AA25821@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!CL-Compiler-mailer
----- Transcript of session follows -----
uux failed. code -1
554 feast!smh... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA25819; Tue, 29 Nov 88 23:27:22 PST
Received: from ucbvax.Berkeley.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA02104; Tue, 29 Nov 88 21:21:51 PST
Received: from Sail.Stanford.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00867; Tue, 29 Nov 88 21:21:41 PST
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:04:25 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07384; 29 Nov 88 19:31 GMT
Date: Tue, 29 Nov 88 19:33:05 GMT
Message-Id: <14986.8811291933@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <ucbarpa!NSS.Cs.Ucl.AC.UK!jeff%aiai.edinburgh.ac.uk>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra <defun!@cs.utah.edu:sandra>,
Kent M Pitman <scrc-stony-brook.arpa!KMP>
In-Reply-To: Sandra J Loosemore's message of Mon, 28 Nov 88 13:14:28 MST
Cc: sail.stanford.edu!CL-Compiler
> The only implementation I know of that implemented COMPILE using
> file compilation (KCL) apparently no longer does so.
My recollection is that KCL prints the data to a file but doesn't
print the code. It used to print the code, which caused problems
with gensyms and the like. But it still prints the constants to
a file and (when LOADing) reads them back in.
But it would be fairly easy to change KCL so that it no longer
printed or read the data.
-- Jeff
∂29-Nov-88 2338 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:38:28 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA04100; Tue, 29 Nov 88 23:37:35 PST
Received: by franz (3.2/3.14)
id AA25840; Tue, 29 Nov 88 23:28:10 PST
Date: Tue, 29 Nov 88 23:28:10 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8811300728.AA25840@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!CL-Compiler-mailer
----- Transcript of session follows -----
uux failed. code -1
554 feast!smh... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA25831; Tue, 29 Nov 88 23:28:10 PST
Received: from ucbvax.Berkeley.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA02106; Tue, 29 Nov 88 21:21:54 PST
Received: from Sail.Stanford.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00870; Tue, 29 Nov 88 21:21:44 PST
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 29 Nov 88 15:03:27 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07292; 29 Nov 88 19:19 GMT
Date: Tue, 29 Nov 88 19:22:02 GMT
Message-Id: <14957.8811291922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <ucbarpa!NSS.Cs.Ucl.AC.UK!jeff%aiai.edinburgh.ac.uk>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra (Sandra J Loosemore) <defun!@cs.utah.edu:sandra>,
Kent M Pitman <NSS.Cs.Ucl.AC.UK!KMP>,
aiai.edinburgh.ac.uk;!28.Nov.88.1314."28 MST",
sail.stanford.edu;!Cc.CL-Compiler
Mmdf-Warning: Parse error in original version of preceding line at .NSS.Cs.Ucl.AC.UK
> The only implementation I know of that implemented COMPILE using
> file compilation (KCL) apparently no longer does so.
My recollection is that KCL prints the data to a file but doesn't
print the code. It used to print the code, which caused problems
with gensyms and the like. But it still prints the constants to
a file and (when LOADing) reads them back in.
But it would be fairly easy to change KCL so that it no longer
printed or read the data.
-- Jeff
∂29-Nov-88 2338 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 23:38:35 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA04107; Tue, 29 Nov 88 23:37:44 PST
Received: by franz (3.2/3.14)
id AA25846; Tue, 29 Nov 88 23:28:24 PST
Date: Tue, 29 Nov 88 23:28:24 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8811300728.AA25846@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!CL-Compiler-mailer
----- Transcript of session follows -----
uux failed. code -1
554 feast!smh... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA25844; Tue, 29 Nov 88 23:28:24 PST
Received: from ucbvax.Berkeley.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA02120; Tue, 29 Nov 88 21:22:04 PST
Received: from Sail.Stanford.EDU by ucbvax.Berkeley.EDU (5.59/1.31)
id AA00879; Tue, 29 Nov 88 21:21:54 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 19:30:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02377g; Tue, 29 Nov 88 19:28:05 PST
Received: by bhopal id AA02975g; Tue, 29 Nov 88 19:26:58 PST
Date: Tue, 29 Nov 88 19:26:58 PST
From: Jim McDonald <ucbarpa!lucid.com!jlm>
Message-Id: <8811300326.AA02975@bhopal>
To: cs.utah.edu!sandra%defun
Cc: DSG.csc.ti.com!Gray, cs.utah.edu!sandra%defun, Sun.COM!cperdue,
sail.stanford.edu!cl-compiler
In-Reply-To: Sandra J Loosemore's message of Tue, 29 Nov 88 19:34:58 MST <8811300234.AA12495@defun.utah.edu>
Subject: issue DEFCONSTANT-NOT-WIRED, version 5
To extend your example, what about something like:
(defmacro defconst (variable value)
`(progn
(eval-when (eval compile load)
(proclaim '(constant ,variable)))
(let ((new-value ,value))
(unless (equal ,variable new-value)
(warn "The constant ~S is being reset from ~S to ~S"
',variable
,variable
new-value)
(makunbound ',variable)
(setq ,variable new-value)
',variable))))
(defconst memory-size (determine-memory-size))
This has the advantage that reloading a file with a defconst in it
will have the nice property of usually not changing the constant
(i.e., EQ-ness is preserved). When the constant does change, a
warning is issued.
The disadvantage is that this makes rather ad hoc use of EQUAL,
but maybe that's not so bad--the behavior is simple and predictable,
and users can roll their own variant of defconst if this one isn't
what they want...
jlm
∂30-Nov-88 0039 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 0039 CL-Cleanup-mailer Merger SETF-FUNCTION-VS-MACRO and SETF-PLACES proposals
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Nov 88 00:39:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02533g; Wed, 30 Nov 88 00:37:34 PST
Received: by bhopal id AA03401g; Wed, 30 Nov 88 00:36:26 PST
Date: Wed, 30 Nov 88 00:36:26 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811300836.AA03401@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-CLEANUP@Sail.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 27 Nov 88 15:00 PST <881128-102707-1360@Xerox>
Subject: Merger SETF-FUNCTION-VS-MACRO and SETF-PLACES proposals
I object to the way in which this merger has been done *** in the
strongest possible way ***.
There has never before been an issue upon which the cleanup committee
successfully reported out two competing proposals. We do not have an
acceptable precedent for sending unresolved alternatives to the committee
as a whole. However, if we in the subcommittee are unable to decide to
drop one of these two proposals, then the presentation of the positions
pro and con should come from the active proponents of each side --- not
from your (misguided, I think) advocacy.
I agree that the two proposals should be presented as "being of one
Issue, and being mutually incompatible"; but I most strongly disagree
that the current Issue format is adequate for the blending in of
seriously opposed alternatives. The "common" sections of References,
Problem Description, Benefits, Rationale etc. presume a common
understanding of what the problem is. But for the two proposals
at hand, the only common thread is the 10 lines (out of the 600 or so)
that call for setf expansions to defaultly turn into setf functions.
Furthermore, the attempted "merger" of the texts from the two proposals
has led to one that is substantially longer, and substantially more
complex, than the two separate ones standing by themselves. For example,
the setf-places version has only 9 items in the "References" section --
but the "merged" version has 25 items, 16 of which are irrelevant to and
distracting from the setf-places. I would much much rather read two
proposals of length N, than one co-mingled one of length 2N -- the
complexity measure of the latter can easily be 4 times greater than
that of either predecessor.
Oddly enough, I have the same feeling towards this issue as Moon,
but from the other side of the fence. I would be only mildly
disappointed if X3J13 decides as a whole to cram "function specs"
downs the throats of all those who have so vociferously rejected
them ("disappointed", because I don't think "function specs" are
good enough -- not because I find lists-as-names disagreeable). But
I would be thoroughly displeased if the committee loses focus on
the choices because the issue is far to complex to read now. I'd
rather see the issue settled by a flip of a coin than risk having
yet more ways to go astray, or more things to argue unproductively
about.
-- JonL --
------- End undelivered message -------
∂30-Nov-88 0506 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 05:06:34 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA15075; Wed, 30 Nov 88 08:05:37 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 13:44:23 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB27551 (5.52.1.1/2.14); Wed, 30 Nov 88 11:31:54 +0100 (MET)
Message-Id: <8811301207.AB27551@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 11:31:54 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA27551 (5.52.1.1/2.14); Wed, 30 Nov 88 13:07:02 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 11:31:54 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA28410; Tue, 29 Nov 88 17:58:30 EST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST
Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST
Date: Tue, 29 Nov 88 17:12:40 EST
From: mcvax!Think.COM!gls
Message-Id: <8811292212.AA00825@joplin.think.com>
To: stony-brook.scrc.symbolics.com!Greenwald
Cc: Think.COM!gls, stony-brook.scrc.symbolics.com!Greenwald,
sail.stanford.edu!common-lisp
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
...
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item would
invalidate the examples.
--Guy
∂30-Nov-88 0522 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 05:21:59 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA16193; Wed, 30 Nov 88 08:21:09 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 13:54:01 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26889 (5.52.1.1/2.14); Wed, 30 Nov 88 10:41:02 +0100 (MET)
Message-Id: <8811300954.AB26889@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 10:41:02 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26889 (5.52.1.1/2.14); Wed, 30 Nov 88 10:54:06 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 10:41:02 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA25813; Mon, 28 Nov 88 21:11:15 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST
Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <mcvax!STONY-BROOK.SCRC.Symbolics.COM!Greenwald>
Subject: inconsistency in backquote spec?
To: sail.stanford.edu!common-lisp
Message-Id: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
If you look at most implementations, and at the examples on pg 351, then
you'd think it should be `(a . b)
However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
I tried Ibuki, Franz, Lucid, and Genera.
In all of them evaluating '`(,@'(a . b)) => `(a . b).
In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil)
while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b)
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
∂30-Nov-88 0522 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 05:22:37 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA16220; Wed, 30 Nov 88 08:21:34 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 13:54:39 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26898 (5.52.1.1/2.14); Wed, 30 Nov 88 10:40:18 +0100 (MET)
Message-Id: <8811300954.AB26898@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 10:40:18 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26898 (5.52.1.1/2.14); Wed, 30 Nov 88 10:54:19 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 10:40:18 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA25414; Mon, 28 Nov 88 21:10:20 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST
Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <mcvax!STONY-BROOK.SCRC.Symbolics.COM!Greenwald>
Subject: inconsistency in backquote spec?
To: sail.stanford.edu!common-lisp
Message-Id: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
If you look at most implementations, and at the examples on pg 351, then
you'd think it should be `(a . b)
However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
I tried Ibuki, Franz, Lucid, and Genera.
In all of them evaluating '`(,@'(a . b)) => `(a . b).
In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil)
while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b)
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
∂30-Nov-88 0532 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 05:32:29 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA16863; Wed, 30 Nov 88 08:31:39 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:00:24 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB27264 (5.52.1.1/2.14); Wed, 30 Nov 88 11:12:34 +0100 (MET)
Message-Id: <8811301024.AB27264@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 11:12:34 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA27264 (5.52.1.1/2.14); Wed, 30 Nov 88 11:24:58 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 11:12:34 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA23944; Tue, 29 Nov 88 17:30:25 EST
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA24518; Tue, 29 Nov 88 13:52:04 PST
Received: from frisky by franz (3.2/3.14)
id AA24713; Tue, 29 Nov 88 13:43:03 PST
Received: by frisky (3.2/3.14)
id AA02600; Tue, 29 Nov 88 13:40:54 PST
From: mcvax!franz!frisky!jkf (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8811292140.AA02600@frisky>
To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase)
Cc: franz!sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST.
<8811291614.AA01479@red.ipsa.dnd.ca>
Date: Tue, 29 Nov 88 13:40:53 PST
Regarding benchmarking Lisps.
1. Declarations are important for speed, but you'll find that some
Lisps will require more specific declarations than others.
For example Sun's Lisp only supports one floating point type so declaring
something to be a 'float' is sufficient for the compiler to open code
the operation. Allegro supports two types of floats so you must declare
either 'single-float' or 'double-float.'
2. Different systems do different amounts of optimizations based on
the settings of the optimization parameters speed, safety and size.
Probably the only comparable values are for speed=3, safety=0, size=0
where each system does maximum optimization. While benchmarks
run at this value are interesting you probably aren't going to
do development with these settings since you aren't going to get
good diagnostics.
Regarding the Lisp on the Sun4.
Allegro is highly optimized for the Sun4 but you have to
add some declarations and specify that speed is important.
The comment was made that a C based Lisp on the Sun4 would
be very fast because of sun's optimizing C compiler.
While it is true that by using C you can take advantage of that
compiler, it is also true that the use of C constrains your
whole system design so you can't use the machine optimally.
I say this from many years experience programming in C parts of the
kernel of Franz Lisp. To cite two examples for the Sun4:
One of the nicest features of the sun4 (sparc) architecture
is the support the the Lisp fixnum data type (there are 'tagged'
versions of the add, subtract and compare instructions).
This allows the compiler to open code +,-,<,<=.. and so on
and if the operands happen to be fixnums (they very often are)
then the operation and fixnum tag check can go on in parallel.
This makes for fast computation in the typical case
and it is completely safe (if the tags aren't fixnum you find out
about it and perform the appropriate operation for the
actual data types).
A C based lisp can't make use of these tagged instructions.
The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asychronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp.
[The use of machine registers to hold certain values was
so important in Franz Lisp that for certain regular
architectures (e.g. vax) an incredible hack was written
by Keith Sklower to modify the assembler language coming
out of the C compiler to change certain memory references
to register references and to fix the register save masks.]
-- John Foderaro
Franz Inc.
jkf%franz.uucp@berkeley.edu
∂30-Nov-88 0532 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 05:32:32 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA16878; Wed, 30 Nov 88 08:31:45 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:02:14 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB27285 (5.52.1.1/2.14); Wed, 30 Nov 88 11:11:01 +0100 (MET)
Message-Id: <8811301025.AB27285@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 11:11:01 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA27285 (5.52.1.1/2.14); Wed, 30 Nov 88 11:25:31 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 11:11:01 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA23834; Tue, 29 Nov 88 17:29:29 EST
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA24518; Tue, 29 Nov 88 13:52:04 PST
Received: from frisky by franz (3.2/3.14)
id AA24713; Tue, 29 Nov 88 13:43:03 PST
Received: by frisky (3.2/3.14)
id AA02600; Tue, 29 Nov 88 13:40:54 PST
From: mcvax!franz!frisky!jkf (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8811292140.AA02600@frisky>
To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase)
Cc: franz!sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST.
<8811291614.AA01479@red.ipsa.dnd.ca>
Date: Tue, 29 Nov 88 13:40:53 PST
Regarding benchmarking Lisps.
1. Declarations are important for speed, but you'll find that some
Lisps will require more specific declarations than others.
For example Sun's Lisp only supports one floating point type so declaring
something to be a 'float' is sufficient for the compiler to open code
the operation. Allegro supports two types of floats so you must declare
either 'single-float' or 'double-float.'
2. Different systems do different amounts of optimizations based on
the settings of the optimization parameters speed, safety and size.
Probably the only comparable values are for speed=3, safety=0, size=0
where each system does maximum optimization. While benchmarks
run at this value are interesting you probably aren't going to
do development with these settings since you aren't going to get
good diagnostics.
Regarding the Lisp on the Sun4.
Allegro is highly optimized for the Sun4 but you have to
add some declarations and specify that speed is important.
The comment was made that a C based Lisp on the Sun4 would
be very fast because of sun's optimizing C compiler.
While it is true that by using C you can take advantage of that
compiler, it is also true that the use of C constrains your
whole system design so you can't use the machine optimally.
I say this from many years experience programming in C parts of the
kernel of Franz Lisp. To cite two examples for the Sun4:
One of the nicest features of the sun4 (sparc) architecture
is the support the the Lisp fixnum data type (there are 'tagged'
versions of the add, subtract and compare instructions).
This allows the compiler to open code +,-,<,<=.. and so on
and if the operands happen to be fixnums (they very often are)
then the operation and fixnum tag check can go on in parallel.
This makes for fast computation in the typical case
and it is completely safe (if the tags aren't fixnum you find out
about it and perform the appropriate operation for the
actual data types).
A C based lisp can't make use of these tagged instructions.
The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asychronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp.
[The use of machine registers to hold certain values was
so important in Franz Lisp that for certain regular
architectures (e.g. vax) an incredible hack was written
by Keith Sklower to modify the assembler language coming
out of the C compiler to change certain memory references
to register references and to fix the register save masks.]
-- John Foderaro
Franz Inc.
jkf%franz.uucp@berkeley.edu
∂30-Nov-88 0549 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 05:48:55 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA17918; Wed, 30 Nov 88 08:48:06 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:45:31 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26235 (5.52.1.1/2.14); Wed, 30 Nov 88 08:47:35 +0100 (MET)
Message-Id: <8811300755.AB26235@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 08:47:35 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26235 (5.52.1.1/2.14); Wed, 30 Nov 88 08:55:40 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 08:47:35 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA27711; Tue, 29 Nov 88 13:58:54 EST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST
Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST
Sender: mcvax!Xerox.COM!"Larry_Masinter.PARC"
Date: 29 Nov 88 10:23:29 PST (Tuesday)
Subject: Re: inconsistency in backquote spec?
From: mcvax!Xerox.COM!"Larry_Masinter.PARC"
To: STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.EDU!common-lisp
In-Reply-To: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28
Nov 88 18:12
Message-Id: <881129-102742-5383@Xerox>
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
Status: PASSED
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
∂30-Nov-88 0606 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 06:05:52 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA19039; Wed, 30 Nov 88 09:05:02 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:51:14 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26408 (5.52.1.1/2.14); Wed, 30 Nov 88 09:06:19 +0100 (MET)
Message-Id: <8811300808.AB26408@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 09:06:19 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26408 (5.52.1.1/2.14); Wed, 30 Nov 88 09:08:20 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 09:06:19 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA04321; Tue, 29 Nov 88 14:58:31 EST
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <mcvax!STONY-BROOK.SCRC.Symbolics.COM!Greenwald>
Subject: inconsistency in backquote spec?
To: Think.COM!gls, STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.edu!common-lisp
In-Reply-To: <8811291735.AA00711@joplin.think.com>
Message-Id: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Or, you could say that the list following a ,@ cannot be dotted.
Either way, I think, requires a minor clarification in the CL spec.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
∂30-Nov-88 0756 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 0756 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 07:54:02 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA21382; Wed, 30 Nov 88 08:47:42 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12828; Wed, 30 Nov 88 08:44:29 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301544.AA12828@defun.utah.edu>
Date: Wed, 30 Nov 88 08:44:27 MST
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: Jim McDonald <jlm@lucid.com>
Cc: Gray@DSG.csc.ti.com, sandra%defun@cs.utah.edu, cperdue@Sun.COM,
cl-compiler@sail.stanford.edu
In-Reply-To: Jim McDonald <jlm@lucid.com>, Tue, 29 Nov 88 19:26:58 PST
Unfortunately, this example is not quite right -- there is a reference to
a potentially unbound variable in the EQUAL test. It's simple enough to
put in a BOUNDP test first.
-Sandra
-------
------- End undelivered message -------
∂30-Nov-88 0805 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 0805 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:05:15 PST
Received: by ti.com id AA22455; Wed, 30 Nov 88 10:04:03 CST
Received: from Kelvin by tilde id AA18129; Wed, 30 Nov 88 09:54:50 CST
Message-Id: <2805897421-15028669@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 30 Nov 88 09:57:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
In-Reply-To: Msg of Tue, 29 Nov 88 19:34:58 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> But version 4 had another problem -- it implicitly assumed that
> switching a variable back and forth between SPECIAL and CONSTANT was
> acceptable style. CLtL is unambiguous that references to undeclared
> free variables are to be treated as references to its special binding,
> yet many implementations issue warnings about doing so as a matter of
> style. I claim that it is just as acceptable for an implementation to
> issue a style warning about changing a DEFVAR to a DEFCONSTANT or vice
> versa.
But you seem to be opting for one possible interpretation of style over
functionality; which doesn't seem like a proper balance. Anyway, a
warning for changing between a DEFVAR and DEFCONSTANT sounds like it would
mainly be useful as a reminder that some code may need to be re-compiled,
but that consideration doesn't apply to these non-wired constants.
> > This still doesn't solve the problem of re-loading the file.
>
> Not directly. On the other hand, it does allow you to do something like:
>
> (defmacro defconst (variable value)
> `(progn
> (eval-when (eval compile load)
> (proclaim '(constant ,variable)))
> (makunbound ',variable)
> (setq ,variable ,value)
> ',variable))
>
> (defconst memory-size (determine-memory-size))
But if you are going to require the user to do that, then we might as well
standardize the macro.
> Basically, we have to decide whether we want to add a macro like
> DEFCONST (or DEFPARAMETER-UNALTERABLE, or whatever we want to call it)
> to the language, or to make the hook it uses available directly, or
> both, or neither. The main arguments for having a CONSTANT
> declaration are that it makes the hook that DEFCONSTANT already uses
> visible, and it also allows for lexically scoped constants.
I still like the declaration approach better.
------- End undelivered message -------
∂30-Nov-88 0821 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 0821 CL-Compiler-mailer Re: Issue DEFCONSTANT-NOT-WIRED, version 5
Received: from RELAY.CS.NET (GW1.CS.NET) by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:21:06 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab00391; 30 Nov 88 9:13 EST
Received: from draper.com by RELAY.CS.NET id aa05292; 30 Nov 88 8:22 EST
Date: Wed, 30 Nov 88 07:38 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue DEFCONSTANT-NOT-WIRED, version 5
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525
Concerning the comment about getting an error when reloading a file that
contains a SETQ of a symbol proclaimed CONSTANT...
Seems to me that the question of what operations or forms in loaded files
can be done more than once (i.e. upon reloading) without signalling errors
really deserves to be a totally separate issue. Perhaps cl-cleanup should
consider addressing it. Such is not limited to setting of constants; it
also affects function definitions, DEFSTRUCTs, CLOS, and lots of other things.
So I wouldn't let the file-reloading problem affect the deliberations on
how a SETQ of a constant is to be done.
------- End undelivered message -------
∂30-Nov-88 0825 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:25:40 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA04432; Wed, 30 Nov 88 11:24:42 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 15:56:11 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB00653 (5.52.1.1/2.14); Wed, 30 Nov 88 14:32:04 +0100 (MET)
Message-Id: <8811301454.AB00653@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 14:32:04 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA00653 (5.52.1.1/2.14); Wed, 30 Nov 88 15:54:51 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 14:32:04 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA05209; Tue, 29 Nov 88 03:39:11 EST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST
Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <mcvax!lucid.com!jonl>
Message-Id: <8811290810.AA00624@bhopal>
To: STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.edu!common-lisp
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂30-Nov-88 0829 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:29:38 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA04932; Wed, 30 Nov 88 11:28:50 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 15:55:07 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB00646 (5.52.1.1/2.14); Wed, 30 Nov 88 14:33:33 +0100 (MET)
Message-Id: <8811301453.AB00646@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 14:33:33 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA00646 (5.52.1.1/2.14); Wed, 30 Nov 88 15:53:47 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 14:33:33 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA05349; Tue, 29 Nov 88 03:40:04 EST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST
Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <mcvax!lucid.com!jonl>
Message-Id: <8811290810.AA00624@bhopal>
To: STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.edu!common-lisp
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂30-Nov-88 0827 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 0827 CL-Compiler-mailer Re: Objects in quoted constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:26:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA22362; Wed, 30 Nov 88 09:19:56 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12847; Wed, 30 Nov 88 09:16:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301616.AA12847@defun.utah.edu>
Date: Wed, 30 Nov 88 09:16:51 MST
Subject: Re: Objects in quoted constants
To: Jon L White <jonl@lucid.com>
Cc: RWK@F.ILA.Dialnet.Symbolics.COM, cperdue@Sun.COM,
cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 29 Nov 88 22:43:50 PST
Well, my $.02 worth on this issue:
My view of the simplest possible implementation of COMPILE-FILE goes
something like this. It is a program that reads forms from the input
file using READ, evaluates things marked (EVAL-WHEN (COMPILE) ...),
and does a code walk to expand all macros. The resulting forms are
then written out to the output file. CLtL specifies that COMPILE-FILE
must do all the other things, but it doesn't say much about how the
file is written. For an extremely simple-minded compiler, it doesn't
seem totally unreasonable to write them using PRINT. (In fact, I seem
to remember that the old DEC-20 CLisp used to do just that.)
One other thing we ought to consider here is the possibility of
support for other file-transformation utilities besides COMPILE-FILE.
As I've mentioned before, there is a person here who has been working
on a type inference system that decorates programs with type
declarations. It reads forms from the input file using READ,
evaluates things marked (EVAL-WHEN (COMPILE) ...), and does a code
walk to expand all macros -- and then PRINTs the output to a text file
that can be compiled with COMPILE-FILE. If we disallow READ/PRINT
semantics for compilation in favor of something more general, that
makes it much more difficult to correctly implement such a filter or
preprocessor.
Personally, I'd be happy with READ/PRINT semantics for constants if it
weren't for array printing being broken. A simple expedient would be
to provide some way to force arrays to print out as #,(make-array ....).
-Sandra
-------
------- End undelivered message -------
∂30-Nov-88 0840 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:39:42 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA05905; Wed, 30 Nov 88 11:38:51 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:47:55 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26243 (5.52.1.1/2.14); Wed, 30 Nov 88 08:46:55 +0100 (MET)
Message-Id: <8811300755.AB26243@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 08:46:55 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26243 (5.52.1.1/2.14); Wed, 30 Nov 88 08:55:53 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 08:46:55 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA27588; Tue, 29 Nov 88 13:57:46 EST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST
Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST
Sender: mcvax!Xerox.COM!"Larry_Masinter.PARC"
Date: 29 Nov 88 10:23:29 PST (Tuesday)
Subject: Re: inconsistency in backquote spec?
From: mcvax!Xerox.COM!"Larry_Masinter.PARC"
To: STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.EDU!common-lisp
In-Reply-To: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28
Nov 88 18:12
Message-Id: <881129-102742-5383@Xerox>
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
Status: PASSED
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
∂30-Nov-88 0840 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 08:39:45 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA05920; Wed, 30 Nov 88 11:38:58 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:49:51 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26251 (5.52.1.1/2.14); Wed, 30 Nov 88 08:40:31 +0100 (MET)
Message-Id: <8811300756.AB26251@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 08:40:31 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26251 (5.52.1.1/2.14); Wed, 30 Nov 88 08:56:03 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 08:40:31 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA29157; Tue, 29 Nov 88 14:13:52 EST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST
Date: Tue, 29 Nov 88 13:55 EST
From: Michael Greenwald <mcvax!STONY-BROOK.SCRC.Symbolics.COM!Greenwald>
Subject: inconsistency in backquote spec?
To: lucid.com!jonl, STONY-BROOK.SCRC.Symbolics.COM!Greenwald
Cc: sail.stanford.edu!common-lisp
In-Reply-To: <8811290810.AA00624@bhopal>
Message-Id: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I agree with this (I think there's a CL cleanup that specifies this
behavior for APPEND and NCONC), and therefore the Lucid backquote
implementation is inconsistent with the definition of APPEND.
(setq d '(a . b))
`(,@d)
`(,@d . nil)
(append [,@d] 'nil)
(append d 'nil)
(append '(a . b) 'nil)
should be (a), as in your example above.
However, it was (a . b) on the version I tried - I didn't try the APPEND
case itself, so maybe in a later version both were made consistent.
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂30-Nov-88 0902 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 09:02:29 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA08336; Wed, 30 Nov 88 12:01:35 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 17:41:16 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB01370 (5.52.1.1/2.14); Wed, 30 Nov 88 17:37:22 +0100 (MET)
Message-Id: <8811301639.AB01370@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 17:37:22 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!fons... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA01370 (5.52.1.1/2.14); Wed, 30 Nov 88 17:39:47 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 17:37:22 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA13556; Wed, 30 Nov 88 00:39:11 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <mcvax!f.ila.dialnet.symbolics.com!RWK>
Subject: Common Lisp for SUNS
To: Bill Pase <red.ipsa.dnd.ca!bill>, sail.stanford.edu!common-lisp
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
∂30-Nov-88 0955 Mailer@MCC.COM Message of 28-Nov-88 10:59:30
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 09:55:36 PST
Date: Wed 30 Nov 88 11:23:33-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Message of 28-Nov-88 10:59:30
Message undelivered after 2 days -- will try for another 1 day:
CL-Object-Oriented-Programming@Hal.CAD.MCC.com: Cannot connect to host
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 28 Nov 88 10:59:32-CST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
-------
∂30-Nov-88 0950 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; jar-cl@zurich.ai.mit.edu; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 0950 CL-Compiler-mailer Re: Objects in quoted constants
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 09:50:29 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA09020; Wed, 30 Nov 88 09:52:46 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA03064; Wed, 30 Nov 88 09:49:15 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA14696; Wed, 30 Nov 88 09:49:43 PST
Date: Wed, 30 Nov 88 09:49:43 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811301749.AA14696@clam.sun.com>
To: jonl@lucid.com, sandra%defun@cs.utah.edu
Subject: Re: Objects in quoted constants
Cc: RWK@F.ILA.Dialnet.Symbolics.COM, cl-compiler@sail.stanford.edu,
cperdue@Sun.COM
> My view of the simplest possible implementation of COMPILE-FILE goes
> something like this. It is a program that reads forms from the input
> file using READ, evaluates things marked (EVAL-WHEN (COMPILE) ...),
> and does a code walk to expand all macros. The resulting forms are
> then written out to the output file. . . .
>
This point of view is one that has been very useful to me as an aid
to thinking about the fundamental problems that a compiler
has in handling references to functions, variables, constants named
and unnamed, etc..
I have never actually come around to the point of view that matching
the semantics of PRINT is the way to go. Perhaps I have had some
element of bias against this, but I have felt for a long time that
PRINT, powerful though it is, is not really adequate for saving and
restoring the state of objects. In CLtL there is no way provided to
force structures to print out readably, no way to print hash tables or
readtables, and array printing leaves out some information. There is
much too limited capability for redefinable printing. (Though structure
types can have their own printers, normal use of the feature makes
file-transforming worse rather than better.) Also, my experience and the
experience of people around me has been that the way PRINT handles
symbols leads to confusion for users. (In particular, the home package
of a symbol may change.)
Anyhow, my conclusion from all of this has been that Common Lisp
PRINT is not suited for dumping out data so it can be reloaded, though
the idea has appeal.
Let's look at this from another point of view. Given PRINT, how hard
is it to write a function that does what one actually needs for
a file transformer? My conclusion: It's not very hard. Even handling
of circular structures isn't so bad given that we have EQ hash tables.
Just as pointed out by Sandra, it isn't necessary to think of a binary
format. With "#.", READ is powerful enough to do whatever is needed,
though I prefer to dump files that reload with LOAD, which implies
that EVAL is available directly because LOAD calls EVAL.
> One other thing we ought to consider here is the possibility of
> support for other file-transformation utilities besides COMPILE-FILE.
> . . .
A type inferencer seems a fine example. I have a cross-reference
ananlyzer that doesn't dump the entire transformed program, but does
dump symbols, sometimes quoted constants, and assorted other informtion.
The cross-reference analyzer would benefit some from availability
of a function that would canonically dump data onto a stream, but
it would benefit even more from a clear specification of how one
should dump data.
SUMMARY:
Attractive as the PRINT/READ duality is, PRINT is *definitely* not
the right thing now, and implementing something that is right would
not be hard at all in my opinion. Maybe less work than writing a
half dozen pieces of committee email.
------- End undelivered message -------
∂30-Nov-88 1050 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1050 CL-Cleanup-mailer *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 10:49:20 PST
Received: from Salvador.ms by ArpaGateway.ms ; 30 NOV 88 10:34:22 PST
Date: 30 Nov 88 10:33 PST
From: masinter.pa@Xerox.COM
Subject: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)
To: CL-CLEANUP@Sail.Stanford.EDU
line-fold: NO
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <881130-103422-2216@Xerox>
JonL has objected to the merger of the two writeups on the grounds that:
a) precedent: we've rarely reported an issue with two proposals
b) partiality: I've not presented the arguments as strongly as the
proponents of either "side" might; my advocacy is "misguided".
c) length:the merged version is as long as the sum of the sizes
of the individual writeups.
I have discovered, to my embarassement, that I neglected to delete
from "NAMED-BY-LIST" a fairly large section that was covered in
"COMMON-PART".
I would like to get a sense of the rest of the committee: would you please
respond to this message on the following question:
***** Should we continue to attempt to arrive at one writeup with two
separate proposals? *******
Thanks,
Larry
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
X3J13 88-002R:
Accessing Slots, Ch. 1 p.11
DEFGENERIC Ch. 2 pp.26-9
DEFMETHOD Ch. 2 pp.39-41
(SETF DOCUMENTATION) Ch. 2 pp.43-5
ENSURE-GENERIC-FUNCTION Ch. 2 pp.46-7
GENERIC-FLET Ch. 2 p.52
GENERIC-LABELS Ch. 2 p.55-6
WITH-ADDED-METHODS Ch. 2 pp.90-1
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
Version 4, 15-Nov-88 JonL, complete rewrite
Version 5, 26-Nov-88 Masinter, merge Versions 3 & 4.
Version 6, 30-Nov-88 Masinter, shorten
PROBLEM DESCRIPTION:
The SETF mechanism in Common Lisp was designed to allow for a
uniform way of refering to the "update" function of an accessor without
having to have separate names for the updator. The SETF macro shields the user
from ever having to know such names; the correlation between an accessor
name and its corresponding updator name, or updating code sequence, was
established by DEFSETF and DEFINE-SETF-METHOD. Update function names
like SET and RPLACA were retained primarily for backward compatibility.
However, in CLOS programming, generic updator functions must
be specified in pieces, by incremental uses of DEFMETHOD. For this,
and a variety of other reasons, the CLOS specification 88-002R
(accepted by X3J13) assumed that lists of the form (SETF <name>) were
acceptable to a wide variety of functions and macros as a way to
specify the "name" of the SETF function. The problem is that this
part of CLOS must be resolved with the rest of Common Lisp.
This issue has two proposals, NAMED-BY-LIST and COMPUTE-UNDERLYING-NAME.
The proposals differ only in how setf functions are named; the common part
is given first.
PROPOSAL (SETF-FUNCTION-VS-MACRO:COMMON-PART):
Add the concept of a "SETF function". Right now, Common Lisp has two
ways to define the behavior of SETF of a form, DEFINE-SETF-METHOD and
DEFSETF. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
Extend the set of valid "place specifiers" as defined on CLtL p 94-97
by adding a clause after the existing ones, to the effect that:
"For any other place specifier, the form
(SETF (-name- a1 a2 ... an) new-value),
will expand into a call to -name-'s corresponding setf-function,
such expansion to be of the form:
(<setf-function-for--name-> y a1 a2 ... an), except that
the left-to-right evalution order of a1 a2 ... an y is preserved."
A setf function receives the new value to be stored as its first
argument. The setf function for -name- should have one more required
parameter than -name-, the first required parameter is the new value
to be stored, and the remaining paramters should be the same as -name-'s
parameters. A setf function should return its first argument, since
SETF is defined to return the new value.
Note that SETF will no longer signal any "unknown place specifier"
errors during macroexpansion, because the default behavior is to
simply construct a call to the setf function [except, however, when
"access-fn" isn't legal as the name of a function; for example,
(SETF ((SPAZ) I1 I2) VALUE) is still syntaticly illegal]. But if
at run time, the "setf function" still hasn't been defined as a
function [such as by DEFUN, DEFMETHOD, setf of SYMBOL-FUNCTION etc.],
then a run-time "undefined function" error may occur.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function can be retrieved by (documentation '(setf foo) 'function).
The two proposals differ in the manner in which the "name" of
a setf function is determined.
The proposal COMPUTE-UNDERLYING-NAME allows these to be
implementation-dependent, and adds two functions,
UNDERLYING-NAME and UNDERLYING-NAME-TO-SPEC, for converting
from specifications of the form (SETF -name-) to the real
name and back.
The proposal NAMED-BY-LIST specifies that the name of
the setf function for -name- *is* the list (SETF -name-),
and extends those places in Common Lisp that deal with
function names to require them to accept such lists.
PROPOSAL (SETF-FUNCTION-VS-MACRO:COMPUTE-UNDERLYING-NAME):
The name of the setf function for -name- is implementation
dependent; in some implementations, it could be a list (as
with the NAMED-BY-LIST proposal below); in other
implementations, it could be a symbol.
- Add a new function, UNDERLYING-NAME of one argument:
(i) on any list like (SETF <name>), it returns a unique,
implementation-dependent name suitable for actual use as
a function name in that implementaion.
(ii) on symbols, it is the identity function; and
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
- Add a new function, UNDERLYING-NAME-TO-SPEC of one argument:
(i) on any argument which results from UNDERLYING-NAME applied
to a list (SETF <name>), UNDERLYING-NAME-TO-SPEC returns
an EQUAL list.
(ii) on any symbol or list not covered by part (i),
UNDERLYING-NAME-TO-SPEC returns it's argument.
(iii) on any other data, it is undefined.
The result of UNDERLYING-NAME should be constant across incarnations
of the same release of an implementation, and should be of a data type
that can be printed out and read back in reliably.
For example, an implementation might choose to define:
(UNDERLYING-NAME '(SETF FOO)) ==> SETF:4.USER.FOO
(UNDERLYING-NAME-TO-SPEC 'SETF:4.USER.FOO) ==> (SETF FOO)
or an implementation could choose to allow lists as names:
(UNDERLYING-NAME '(SETF FOO)) ==> (SETF FOO)
(UNDERLYING-NAME-TO-SPEC '(SETF FOO)) ==> (SETF FOO)
-- Modify the wording in the standard which describes parts imported
from the CLOS specification so as not to imply that lists are
suitable as function names. In particular,
(a) phrases like "... if <function-specifier> names a function" should
be changed to a phrase like "... if <function-specifier> refers to
a defined function", or possibly even something like
"... if (UNDERLYING-NAME <function-specifier>) names a function"
(b) phrases like "(FBOUNDP <function-specifier>)" should be changed
into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
else other terminology should express the intent of what is to
be said. For example, instead of saying: "When (FBOUNDP <f-s>)
is true ..." one could just as well say "When <f-s> refers to
a defined function ..." The choice of which of these two formats
to use is an editorial one.
(c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
or else other terminology should express the intent of what is to
be said. For example, one might say "... the function referred
to by <f-s>". The choice of which of these two formats to use is
an editorial one.
Note that forms like
(DEFMETHOD (SETF FOO) ...)
will expand similarly to
(DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
except that the implicit block name surrounding the body of the method
will be FOO and not (UNDERLYING-NAME '(SETF FOO)).
The underlying call to ADD-METHOD will see the real function name used
for the updator function. The user-level interface of CLOS can still
present the list format as acceptable; it is only the implementation of
DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
"real" name.
In an implementation note, point out that UNDERLYING-NAME-TO-SPEC
could be used by debuggers to print out something more user-comprehensible
than the internal names that an implementation might use.
PROPOSAL (SETF-FUNCTION-VS-MACRO:NAMED-BY-LIST):
The "name" of the setf function for -name- is a list (SETF -name-),
where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
Modify the following functions, macros, special forms, and declarations:
COMPILE function, DEFUN macro, DISASSEMBLE function, DOCUMENTATION function,
FBOUNDP function, FLET special form, FMAKUNBOUND function, FTYPE declaration,
FUNCTION special form, FUNCTION declaration, INLINE declaration,
NOTINLINE declaration, LABELS special form
to accept such lists in addition to symbols as function names, so that
setf functions can be defined and manipulated.
Note that, although it is possible to lexically redefine the function definition
of (SETF -name-), the macro expansion of SETF is not affected by such
lexical redefinition.
Clarify that (documentation foo 'setf) is only affected by invocations
of defsetf and define-setf-method. (As specified above, the DOCUMENTATION
function is modified so that (documentation '(setf foo) 'function) will
retrieve documentation strings established by
(defun (setf foo) (arg) "This is documentation..." ....)
Examples:
;;If SETF of SUBSEQ were not already built into Common Lisp,
;it could be defined, under NAMED-BY-LIST, as:
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;; while with COMPUTE-UNDERLYING-NAME, as:
(setf (symbol-function (underlying-name '(setf subseq)))
#'(lambda (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value i)))))
;;Another example, showing a locally defined setf function.
;; with NAMED-BY-LIST:
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;; with COMPUTE-UNDERLYING-NAME:
; First, define MIDDLE-REF to be an accessor function as follows:
(defun middle-ref (vec i)
(check-type i fixnum)
(aref vec (ceiling i 2)))
;; then, even given:
(defun #.(underlying-name '(setf middle-ref)) (new-element vec i)
(check-type i fixnum)
(setf (aref vec (ceiling i 2)) new-element))
(flet ((#.(underlying-name '(setf middle-ref)) (new-element vec i)
;;"wide-body" version of set-middle-ref
(declare (ignore i))
(fill vec new-element :end (ceiling i 2))))
(setf (middle-ref "abc" 1) #\z))
;;;GET-SETF-METHOD could implement setf functions by calling
;;;this function when none of the other rules of CLtL p 94-7 apply:
(defun get-setf-method-for-setf-function (form)
(let ((access-fn (car form))
(new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(,@
#+NAMED-BY-LIST
`(funcall #'(setf ,access-fn))
#+COMPUTE-UNDERLYING-NAME
`(,(underlying-name `(setf ,access-fn)))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
Both proposals allow a more functional appropach to dealing with
SETF, and bring the CLOS and Common Lisp parts of the standard into
more alignment. COMPUTE-UNDERLYING-FUNCTION does so by adding functions
to go between the "specification" of (SETF -name-) to the name
actually used, while NAMED-BY-LIST does so by extending a number
of already existing Common Lisp functions, macro and special forms.
SETF functions take the "new value" as the first argument to allow
for defining them on accessors that have &REST and &KEY arguments.
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a feature similar,
but not compatible with, NAMED-BY-LIST, in that they allow setting
functions named (SETF reader). We don't know of any implementation
that has precisely the proposed feature.
For example, This will be an incompatible change for Symbolics,
since it already has setf functions but they do not take the
same arguments as proposed here.
COST TO IMPLEMENTORS:
For either proposal, the SETF macro expansion would have to be
extended to generate the appropriate call on the setf function.
The additional cost of proposal COMPUTE-UNDERLYING-NAME is low;
implementations would need to add the two proposed functions.
In addition, implementations would need to modify their
CLOS implementation to use UNDERLYING-NAME where appropriate.
[A sample implementation is given at the end of the proposal.]
The cost of proposal NAMED-BY-LIST is higher, since many other
functions, macros and special forms would have to be extended to
deal with the SETF specifications. The main cost is generalization
of a few functions to accept lists beginning with SETF where they
now accept only symbols. Implementations must add a data structure
to store the function definition of a setf function, however, this can
be done with property lists or generated symbols.
COST TO USERS:
Both proposals are basically upward-compatible changes for currently
portable Common Lisp programs.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue with NAMED-BY-LIST is programs
that assume that all function names are symbols. They may use GET to
access properties of a function name or use EQ or EQL (perhaps via
MEMBER or ASSOC) to compare function names for equality. Such programs
will need improvement before they can understand programs that use
the new feature.
Both proposals remove some macro-expansion error checking, since
detection of incorrect SETF expansion will be postponed to run-time.
This is a minor deficiency, as it puts invocation of SETF functions
on the same footing as other function calls.
COST OF NON-ADOPTION:
Common Lisp and CLOS would be significantly inconsistent; some major
rethinking of CLOS would be required.
BENEFITS:
Improve usability of SETF. Avoids cost of non-adoption.
With NAMED-BY-LIST, current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
could be replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
With NAMED-BY-LIST, a convenent way of lexically defining
or redefining the behavior of SETF would be allowed.
PERFORMANCE IMPACT:
Negligible; ether proposal might make an implementation slightly
larger.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
The proposal NAMED-BY-LIST allows lists of the form (SETF -name-) to be
used in many places where only symbols were allowed before. Some
people feel this is unesthetic, because it is at odds with many
current descriptions of Common Lisp say that names are symbols.
DISCUSSION:
This issue has been in discussion in the CLOS committee and at X3J13
for over a year. Versions of the proposal were distributed, discussed,
and voting tabled at three successive meetings of X3J13. The proposal
previously distributed most resembles the NAMED-BY-LIST proposl contained
in this version.
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. Neither proposal attempts to
change that aspect of Common Lisp.
Most of the objection to previous proposals were based on
introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
The CLOS group unsuccessfully tried a number of alternatives that
did not require naming the setf function at all. However,
fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
!
Appendix: Sample implementation of COMPUTE-UNDERLYING-NAME
The following code can be used by an implementation which doesn't
have "function specs" to implement the COMPUTE-UNDERLYING-NAME proposal:
;;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: SYSTEM; Base: 10 -*-
;;;
;;; Author: JonL White, 15-Nov-88
;;;
(in-package "SYSTEM") ;or, your development package
(eval-when (eval compile load)
;;; The SETF package should be reserved for this purpose
;;;
(or (find-package "SETF")
(make-package "SETF" :use nil))
(defparameter *setf-package* (find-package "SETF"))
(unless (and (null (package-use-list *setf-package*))
(null (package-used-by-list *setf-package*)))
(error "SETF package has connections?"))
;;; "Internal Markers", to be used for uninterned symbols.
;;;
(export (intern "SETF-SPEC" *setf-package*) *setf-package*)
(export (intern "SETF-NAME" *setf-package*) *setf-package*)
)
(eval-when (eval compile)
(defmacro setf-spec-p (x)
(let ((spec (gensym)))
`(LET ((,spec ,x))
(AND (CONSP ,spec)
(EQ (CAR ,spec) 'SETF)
(CONSP (CDR ,spec))
(NULL (CDDR ,spec))
(SYMBOLP (SECOND ,spec))))))
)
(defun UNDERLYING-NAME (spec)
(cond
((symbolp spec)
spec)
((setf-spec-p spec)
(let* ((accessor (second spec))
(accessor-name (symbol-name accessor))
(home-package (symbol-package accessor)))
(if home-package
(let* ((package-name (package-name home-package))
;; 'spec-name' is a form like "~D.~A.~A", but FORMAT has a
;; problem with global print parameters like *print-radix*
(spec-name (concatenate 'string
(write-to-string (length package-name)
:radix nil :base 10 :length nil :level nil)
"."
package-name
"."
accessor-name))
(updator (or (find-symbol spec-name *setf-package*)
(let ((sym (intern spec-name *setf-package*)))
(export sym *setf-package*)
sym))))
;; A possible optimization, which trades off space for time, is
;; as follows; see definition of UNDERLYING-NAME-TO-SPEC below
;;(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)
(or (get accessor 'setf:setf-name)
(let* ((uname (concatenate 'string "SET-" accessor-name))
(updator (make-symbol uname)))
(setf (get accessor 'setf:setf-name) updator)
(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)))))
(t
(error "~S is an invalid arg for ~S" spec 'UNDERLYING-NAME))))
(defun UNDERLYING-NAME-TO-SPEC (x)
(cond
((not (symbolp x))
(if (setf-spec-p x)
x
(error "~S is an invalid arg for ~S"
x 'UNDERLYING-NAME-TO-SPEC)))
((get x 'setf:setf-spec))
(t
(let ((home-package (symbol-package x)))
(if (not (eq home-package *setf-package*))
x
(let ((name (symbol-name x))
accessor package-name)
;; Unpack the name, which is a form like "~D.~A.~A"
(multiple-value-bind (nchars starti)
(parse-integer name :radix 10 :junk-allowed t)
(incf starti)
(setq package-name (subseq name starti (incf starti nchars)))
(incf starti)
(setq accessor (find-symbol (subseq name starti)
(find-package package-name)))
(unless accessor
(error "~S failed to parse in ~S"
x 'UNDERLYING-NAME-TO-SPEC))
`(SETF ,accessor))))))))
----- End Forwarded Messages -----
------- End undelivered message -------
∂30-Nov-88 1208 Postmaster@aramis.rutgers.edu Returned mail: Host unknown
Received: from aramis.rutgers.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:07:31 PST
Received: from SAIL.STANFORD.EDU by aramis.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA08779; Wed, 30 Nov 88 15:06:32 EST
Date: Wed, 30 Nov 88 15:06:32 EST
From: Postmaster@aramis.rutgers.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8811302006.AA08779@aramis.rutgers.edu>
To: <CL-Object-Oriented-Programming-mailer@sail.stanford.edu>
----- Transcript of session follows -----
550 bylander%osu-20@ohio-state.arpa... Host unknown
----- Unsent message follows -----
Received: from SAIL.STANFORD.EDU by aramis.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA08774; Wed, 30 Nov 88 15:06:32 EST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
∂30-Nov-88 1158 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1158 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R, 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:58:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 88 11:31:31 PST
Date: 30 Nov 88 11:12 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R, 4)
In-reply-to: ROSENKING@A.ISI.EDU's message of 27 Oct 88 09:50 EDT
To: ROSENKING@A.ISI.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881130-113131-2391@Xerox>
I'm sorry that you didn't get a copy of Walter's version 3. I am forwarding
to you in a separate message all of the relevant mail on the topic that
didn't explicitly include you in the cc list. (I guess we had no warning
that you were preparing a version 3.)
You say "My version is separate and hopefully unique."I don't hope for
unique versions; I hope for merged ones. Are you dissastified with Version
4? (Frankly, I have not taken the time to review the differences between
the various versions.)
------- End undelivered message -------
∂30-Nov-88 1200 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1200 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:58:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 11:56:41 PST
Date: 30 Nov 88 11:30 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R)
In-reply-to: ROSENKING@A.ISI.EDU's message of 27 Oct 88 09:50 EDT
To: ROSENKING@A.ISI.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881130-115641-2461@Xerox>
<<I thought for a minute that David Moon had actually produced a new
version 4, but I was mistaken; this message supersedes the previous one
"Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R, 4)"
>>
I'm sorry that you didn't get a copy of Walter's version 3. I have
forwarded to you, in a separate message, all of the relevant mail on the
topic that didn't explicitly include you in the cc list. (I guess we had no
warning that you were preparing a version 3.)
You say "My version is separate and hopefully unique."I don't hope for
unique versions; I hope for merged ones. Are you dissastified with Walter
van Roggen's Version 3? (Frankly, I have not taken the time to review the
differences between the various versions.)
------- End undelivered message -------
∂30-Nov-88 1210 MAILER-DAEMON@spice.cs.cmu.edu Unable to deliver mail
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:10:39 PST
Date: Wed, 30 Nov 88 15:08:32 EST
From: MAILER-DAEMON@spice.cs.cmu.edu
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Unable to deliver mail
----- Transcript of session follows -----
joseph.ginder... User unknown
----- Unsent message follows -----
Received: from SAIL.STANFORD.EDU by SPICE.CS.CMU.EDU; 30 Nov 88 15:07:47 EST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
∂30-Nov-88 1215 Mailer failed mail returned
To: CL-Object-Oriented-Programming-mailer
The following message was undeliverable to recipient(s):
kcquayle@BBN.COM
Here is how the remote host replied to this mail address:
kcquayle@BBN.COM
550 (USER) Unknown user name in "kcquayle@BBN.COM"
------- Begin undelivered message: -------
30-Nov-88 1147 CL-Object-Oriented-Programming-mailer compile-time side effects
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
------- End undelivered message -------
∂30-Nov-88 1147 Mailer failed mail returned
To: CL-Object-Oriented-Programming-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
ajcole%aivax.ai.leeds.ac.uk@CS.UCL.AC.UK; HWB1%CAM.PHX%CAM.ENG-ICF@CS.UCL.AC.UK; hthompson%eusip@CS.UCL.AC.UK; mklein@B.CS.UIUC.EDU; commonlisp@GSWD-VMS.ARPA
Here is how the remote host(s) replied to these mail addresses:
kcquayle@BBN.COM
451 Nameserver timeout during parsing
ajcole%aivax.ai.leeds.ac.uk@CS.UCL.AC.UK
550 (NAUTH) Bad authorization for address "ajcole <@CS.UCL.AC.UK:ajcole@aivax.ai.leeds.ac.uk>": Sender 'cl-object-oriented-programming-mailer@sail.stanford.edu' not authorized. Mail authorisation@UK.AC.UCL.CS (with an empty message) for help.
HWB1%CAM.PHX%CAM.ENG-ICF@CS.UCL.AC.UK
550 (BHST) Unknown host/domain name in "HWB1 <@CS.UCL.AC.UK,@CAM.ENG-ICF:HWB1@CAM.PHX>"
hthompson%eusip@CS.UCL.AC.UK
550 (NAUTH) Bad authorization for address "hthompson <@CS.UCL.AC.UK:hthompson@eusip>": Sender 'cl-object-oriented-programming-mailer@sail.stanford.edu' not authorized. Mail authorisation@UK.AC.UCL.CS (with an empty message) for help.
mklein@B.CS.UIUC.EDU
554 <mklein@B.CS.UIUC.EDU>... 550 User unknown
------- Begin undelivered message: -------
30-Nov-88 1147 CL-Object-Oriented-Programming-mailer compile-time side effects
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
------- End undelivered message -------
∂30-Nov-88 1209 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1209 CL-Cleanup-mailer Re: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:09:10 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA04252; Wed, 30 Nov 88 15:06:02 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01386; Wed, 30 Nov 88 14:26:34 EST
Message-Id: <8811301926.AA01386@mist.>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)
In-Reply-To: Your message of 30 Nov 88 10:33:00 -0800.
<881130-103422-2216@Xerox>
Date: Wed, 30 Nov 88 14:26:32 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I think that two separate proposals are easier to understand. We can
try to attach a joint cover letter for the vote to indicate that only
one should pass, but even that is probably unnecessary.
------- End undelivered message -------
∂30-Nov-88 1225 Mailer@XX.LCS.MIT.EDU Message of 30-Nov-88 15:20:35
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:25:08 PST
Date: Wed 30 Nov 88 15:21:46-EST
From: The Mailer Daemon <Mailer@XX.LCS.MIT.EDU>
To: CL-Windows-mailer@SAIL.STANFORD.EDU
Subject: Message of 30-Nov-88 15:20:35
Message failed for the following:
jloaiza%oracle@hplabs.hp.com: 554 <jloaiza%oracle@hplabs.hp.com>... Nameservice says unknown host or domain name
------------
Received: from ZERMATT.LCS.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 30 Nov 88 15:20:37-EST
Received: from SAIL.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 214366; 30 Nov 88 15:21:04 EST
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:14:31 PST
Received: by goldhill.com; Wed, 30 Nov 88 15:09:51 EST
Date: Wed, 30 Nov 88 15:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8811302009.AA14436@goldhill.com>
To: DALY@ibm.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Timothy Daly's message of 18 Nov 88 09:35:30 EST <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.
-------
∂30-Nov-88 1219 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1219 CL-Cleanup-mailer Issue: STREAM-ACCESS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:18:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 11:58:53 PST
Date: 30 Nov 88 11:43 PST
From: masinter.pa@Xerox.COM
Subject: Issue: STREAM-ACCESS (version 2)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881130-115853-2468@Xerox>
KMP's notes:
" A straw poll was taken to see if people wanted TYPES & -P FNS,
just TYPES, or just -P FNS. Alas, I didn't record the outcome
of this vote, though there were definitely people in all three
camps. I think we said we'd put all three options on the letter
ballot.
"
I tried to separate out the acessor/predicate/type parts of
this proposal into separate sections so that we could do
this.
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
30-Nov-88, version 2 by Masinter
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
The accessors wanted are those associated with broadcast streams,
concatenated streams, echo streams, file streams, string streams,
synonym streams, two way streams.
There are three proposals, which differ only by the whether
they include types, type predicates, or both, in addition to
the stream component acessors. Ballots can be either for
one of the proposals or none. (Other combinations of, say,
accessors without either predicates or types, or types without
accessors, do not seem reasonable and are not being proposed
at this time.)
Proposal STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
First, add a function to determine whether a stream is "OPEN":
OPEN-STREAM-P stream [Function]
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Streams are "open" until they have been closed with
CLOSE, or, the dynamic context of the creating/accessing
macros of WITH-OUTPUT-TO-STRING, WITH-OPEN-FILE,
WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM,
have been exited.
There are three kinds of things to add associated with each kind of
stream: data types, predicates, accessors.
Stream data types:
BROADCAST-STREAM (returned by MAKE-BROADCAST-STREAM)
CONCATENATED-STREAM (returned by MAKE-CONCATENATED-STREAM)
ECHO-STREAM (returned by MAKE-ECHO-STREAM)
FILE-STREAM (returned by OPEN or created by WITH-OPEN-FILE)
STRING-STREAM (returned by MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM, and created by WITH-INPUT-FROM-STRING
and WITH-OUTPUT-TO-STRING and FORMAT with second argument NIL)
SYNONYM-STREAM (created by MAKE-SYNONYM-STREAM)
TWO-WAY-STREAM (created by MAKE-TWO-WAY-STREAM)
The stream data types are all subtypes of type STREAM and are mutually
exclusive. (In particular, a synonym stream is only of type SYNONYM-STREAM.)
Stream Predicates:
Each of these returns T if the object is of the corresponding type,
and NIL otherwise.
BROADCAST-STREAM-P, CONCATENATED-STREAM-P,
ECHO-STREAM-P, FILE-STREAM-P, STRING-STREAM-P,
SYNONYM-STREAM-P, TWO-WAY-STREAM-P
Note that the predicates do not "follow the link" of a synonym
stream.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Proposal: STREAM-ACCESS:ADD-TYPES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to leave out the
stream type predicates.
Proposal: STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to not
identify new data types. The accessors act as if the types were specified
(i.e., are mutually excusive).
Current Practice:
VAX LISP implements ADD-TYPES-PREDICATES-ACCESSORS.
We have not surveyed other implementations.
Cost to Implementors:
All of the proposals are reasonably simple to implement, since the information
must be present for nearly all types.
Cost to Users:
The proposals are upward-compatible, and should have little impact.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
The behavior of OPEN-STREAM-P on, for example, broadcast streams, might
be specified in a variety of alternative ways. This specification seems the simplest.
There are three proposals for voting because there was no agreement at the
October X3J13 on the issue of whether types, predicates, or both should be
added.
There was a proposal at one time to add a new function FOLLOW-SYNONYM-STREAM
which could be written as
(defun follow-synonym-stream (x)
(if (synonym-stream-p x)
(follow-synonym-stream (symbol-value (synonym-stream-symbol x)))
x))
i.e., which chases through zero or more synonym stream indirections.
------- End undelivered message -------
∂30-Nov-88 1238 mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET Returned mail: Service unavailable
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:38:36 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA19051; Wed, 30 Nov 88 09:05:08 EST
Received: by mcvax.cwi.nl with SMTP; Wed, 30 Nov 88 14:53:01 +0100 (MET)
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AB26415 (5.52.1.1/2.14); Wed, 30 Nov 88 09:03:44 +0100 (MET)
Message-Id: <8811300808.AB26415@hp4nl.nluug.nl>
Date: Wed, 30 Nov 88 09:03:44 +0100
From: mcvax!hp4nl.nluug.nl!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
To: Common-Lisp-mailer@SAIL.Stanford.EDU
Cc: Postmaster@hp4nl.nluug.nl
Subject: Returned mail: Service unavailable
----- Transcript of session follows -----
>>> HELO hp4nl.nluug.nl
<<< 553 hp4nl.nluug.nl I refuse to talk to myself
554 botter!cs.vu.nl!biep... Service unavailable: No such file or directory
----- Unsent message follows -----
Return-Path: <mcvax!SAIL.Stanford.EDU!Common-Lisp-mailer>
Received: from mcvax by hp4nl.nluug.nl with UUCP via EUnet
id AA26415 (5.52.1.1/2.14); Wed, 30 Nov 88 09:08:30 +0100 (MET)
Received: by mcvax.cwi.nl via EUnet; Wed, 30 Nov 88 09:03:44 +0100 (MET)
Received: from SAIL.STANFORD.EDU by uunet.UU.NET (5.59/1.14)
id AA03357; Tue, 29 Nov 88 14:48:39 EST
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST
Received: by tut.cis.ohio-state.edu (5.59/2.881128)
id AA25824; Tue, 29 Nov 88 14:12:36 EST
Date: Tue, 29 Nov 88 14:12:36 EST
From: Arun Welch <mcvax!cis.ohio-state.edu!welch>
Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu>
To: think.com!barmar
Cc: sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
>
>Kyoto CL is not generally considered a high-performance Lisp. Its major
>feature is its portability, since it is written mostly in C and its
>compiler uses C as the intermediate language. It is also well-known for
>being very faithful to CLtL, implementing all and only what the book
>says.
We're in the process of coming up with a decision on what lisp to get
for the University, and have been looking at Ibuki, Franz, and Envos
(and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has
been benchmarking them on Sun-3's and Sun-4's, and we've noticed that
in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind
of amazed by this, until we realised that Ibuki uses the native C
compiler, which is optimising for the SPARC architecture on the -4,
while none of the others were. This wasn't an across-the-board
speedup, just for some of the things we tried. I'd pretty much agree
with your other assessment of Kyoto CL, modulo the fact that Ibuki has
extended it somewhat (folding in the new error system, for example).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
∂30-Nov-88 1241 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1241 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:40:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA02669; Wed, 30 Nov 88 13:40:21 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA13027; Wed, 30 Nov 88 13:40:15 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811302040.AA13027@defun.utah.edu>
Date: Wed, 30 Nov 88 13:40:13 MST
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Wed, 30 Nov 88 09:57:01 CST
> Date: Wed, 30 Nov 88 09:57:01 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> Anyway, a
> warning for changing between a DEFVAR and DEFCONSTANT sounds like it would
> mainly be useful as a reminder that some code may need to be re-compiled,
> but that consideration doesn't apply to these non-wired constants.
Not necessarily. Suppose I have declared FOO with DEFVAR, and then
later on at (perhaps in another file) I redeclare it with DEFCONSTANT.
I think an implementation would be justified in signalling a warning
to indicate: "Hey!! Somebody else has already said they want to treat
FOO like an ordinary special variable. Do you really want to make it
an error to specially bind it or modify its value?" Or the opposite
situation; suppose I have originally declared BAR with DEFCONSTANT and
then redeclare it with DEFVAR. Again, I think it's quite reasonable
to signal an error to say: "Hey!!! Somebody else is expecting that the
value of BAR is not going to change. Making it into an ordinary
variable may break things."
-Sandra
-------
------- End undelivered message -------
∂30-Nov-88 1251 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1251 CL-Compiler-mailer Re: CONSTANT-COMPILABLE-TYPES
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:51:02 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA18149; Wed, 30 Nov 88 12:53:42 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA11316; Wed, 30 Nov 88 12:49:36 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA14971; Wed, 30 Nov 88 12:50:30 PST
Date: Wed, 30 Nov 88 12:50:30 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811302050.AA14971@clam.sun.com>
To: franz!frisky!jkf@Sun.COM
Subject: Re: CONSTANT-COMPILABLE-TYPES
Cc: cl-compiler@sail.stanford.edu
****** I'm wondering why you didn't go further and say that during
****** file compilation occurances of the same uninterned symbol in different
****** constants must be eq when both constant expressions are loaded in?
****** Do you not believe that this should be the case or is this just
****** the wrong place to state it?
It seemed to me that keeping references to the same uninterned
symbol EQ across an entire file compilation is one more step
harder than requiring EQ'ness within one quoted constant, and I
just hesitated at that step. Also, it wasn't clear to me whether
retaining EQ'ness across a file would solve a significant set
of problems for people.
------- End undelivered message -------
∂30-Nov-88 1300 mad!uucp@labrea.stanford.edu
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 13:00:23 PST
Received: by labrea.stanford.edu; Wed, 30 Nov 88 12:59:13 PST
Date: Wed, 30 Nov 88 12:59:13 PST
From: mad!uucp@labrea.stanford.edu
Message-Id: <8811302059.AA15721@labrea.stanford.edu>
Apparently-To: CL-Windows-mailer@SAIL.Stanford.EDU
remote execution [uucp job labreaCLBw3 (11/30-12:43:24)]
rmail mlj
exited with status 2
===== stderr was =====
Can't send to mlj
∂30-Nov-88 1302 postmaster@hudson.dec.com Mail Delivery Problem
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 30 Nov 88 13:02:17 PST
Date: 30 Nov 88 15:39:39 EST
From: "SMTP MAILER" <postmaster@hudson.dec.com>
Subject: Mail Delivery Problem
To: "cl-object-oriented-programming-mailer" <cl-object-oriented-programming-mailer@sail.stanford.edu>
----Reason for mail failure follows----
Sending mail to recipient(s) vanroggen :
Couldn't make final delivery.
----Transcript of message follows----
Received: from SAIL.Stanford.EDU by hudson.dec.com with SMTP ;
Wed, 30 Nov 88 15:18:46 EST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
∂30-Nov-88 1244 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1244 CL-Compiler-mailer Re: CONSTANT-COMPILABLE-TYPES
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:43:49 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA17974; Wed, 30 Nov 88 12:46:26 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA11099; Wed, 30 Nov 88 12:42:58 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA14949; Wed, 30 Nov 88 12:43:52 PST
Date: Wed, 30 Nov 88 12:43:52 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811302043.AA14949@clam.sun.com>
To: cl-compiler@sail.stanford.edu
Subject: Re: CONSTANT-COMPILABLE-TYPES
----- Begin Forwarded Message -----
From franz!frisky!jkf Wed Nov 30 12:29:42 1988
From: franz!frisky!jkf (John Foderaro)
To: franz!sun!cperdue
Subject: CONSTANT-COMPILABLE-TYPES
Date: Wed, 30 Nov 88 11:11:37 PST
Thanks for sending me that proposal. It looks ok to me, my only
comment was about the section on symbols:
If a symbol is not interned, i.e. its home package is NIL, it is
similar as a constant to any symbol with the same name and no home
package. In addition, all occurrences of the same uninterned symbol
in the same constant expression must be EQ after file-compilation and
loading. Uninterned symbols not EQ at compile time must never be
coalesced by file-compilation and loading.
****** I'm wondering why you didn't go further and say that during
****** file compilation occurances of the same uninterned symbol in different
****** constants must be eq when both constant expressions are loaded in?
****** Do you not believe that this should be the case or is this just
****** the wrong place to state it?
----- End Forwarded Message -----
------- End undelivered message -------
∂30-Nov-88 1336 COMSAT%MC.LCS.MIT.EDU@XX.LCS.MIT.EDU Msg of Wednesday, 30 November 1988 16:33-EST
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 13:35:29 PST
Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Wed 30 Nov 88 16:33:48-EST
Date: Wed, 30 Nov 88 16:34:07 EST
From: Communications Satellite <COMSAT@MC.LCS.MIT.EDU>
Subject: Msg of Wednesday, 30 November 1988 16:33-EST
To: "@XX.LCS.MIT.EDU:CL-Object-Oriented-Programming-mailer@SAIL.Stanford.EDU"@XX.LCS.MIT.EDU
Message-ID: <510329.881130@MC.LCS.MIT.EDU>
FAILED: rg at RICE-CHEX.AI.MIT.EDU; Recipient name apparently rejected.
Last reply was: {550 <rg@RICE-CHEX.AI.MIT.EDU>... User unknown}
Failed message follows:
-------
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Nov 88 16:06:49 EST
Received: from SAIL.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 30 Nov 88 16:06:02-EST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
∂30-Nov-88 1340 COMSAT%MC.LCS.MIT.EDU@XX.LCS.MIT.EDU Msg of Wednesday, 30 November 1988 16:37-EST
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 13:40:43 PST
Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Wed 30 Nov 88 16:37:20-EST
Date: Wed, 30 Nov 88 16:37:34 EST
From: Communications Satellite <COMSAT@MC.LCS.MIT.EDU>
Subject: Msg of Wednesday, 30 November 1988 16:37-EST
To: "@XX.LCS.MIT.EDU:CL-Object-Oriented-Programming-mailer@SAIL.Stanford.EDU"@XX.LCS.MIT.EDU
Message-ID: <510339.881130@MC.LCS.MIT.EDU>
FAILED: jerryb at RICE-CHEX.AI.MIT.EDU; Recipient name apparently rejected.
Last reply was: {550 <jerryb@RICE-CHEX.AI.MIT.EDU>... User unknown}
Failed message follows:
-------
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Nov 88 16:07:49 EST
Received: from SAIL.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 30 Nov 88 16:06:02-EST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros. Unfortunately, I'm not at all sure what the side effects
should be. Can somebody who really groks CLOS please help me out?
DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations). Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file. Does this mean that
it must also construct a real class object at compile time? Are the
reader, writer, and accessor functions defined at compile time?
DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time. Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time? Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?
DEFINE-METHOD-COMBINATION: My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?
DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time. Is the FBOUNDP test
supposed to happen at runtime or compiletime? If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time? Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time?
-Sandra
-------
∂30-Nov-88 1215 Mailer failed mail returned
To: CL-Windows-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
puccio@MEDIA-LAB.MEDIA.MIT.EDU; aidel@ecs.umass.edu; pierce%rd1632@ncrlnk.dayton.ncr.com; lispx-gmd@gmdzi.uucp@UUNET.UU.NET; eric@SCUBED.ARPA; marone@NRL-AIC.ARPA; hota@NRL-AIC.ARPA; York@Chuck-Jones.ILA-West.Dialnet.Symbolics.COM
Here is how the remote host(s) replied to these mail addresses:
puccio@MEDIA-LAB.MEDIA.MIT.EDU
550 <puccio@MEDIA-LAB.MEDIA.MIT.EDU>... User unknown
lispx-gmd@gmdzi.uucp@UUNET.UU.NET
550 <"lispx-gmd@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
tk%moss@ATT.ARPA
421 research.att.com too busy, please try later
blewett%research.att.com%siriusb@RESEARCH.ATT.COM
421 research.att.com too busy, please try later
------- Begin undelivered message: -------
30-Nov-88 1215 CL-Windows-mailer common lisp stream to an X window
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:14:31 PST
Received: by goldhill.com; Wed, 30 Nov 88 15:09:51 EST
Date: Wed, 30 Nov 88 15:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8811302009.AA14436@goldhill.com>
To: DALY@ibm.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Timothy Daly's message of 18 Nov 88 09:35:30 EST <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.
------- End undelivered message -------
∂30-Nov-88 1405 postmaster@hudson.dec.com Mail Delivery Problem
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 30 Nov 88 14:05:33 PST
Date: 30 Nov 88 16:43:08 EST
From: "SMTP MAILER" <postmaster@hudson.dec.com>
Subject: Mail Delivery Problem
To: "cl-object-oriented-programming-mailer" <cl-object-oriented-programming-mailer@sail.stanford.edu>
----Reason for mail failure follows----
Sending mail to recipient(s) vanroggen :
Couldn't make final delivery.
%MAIL-E-LOGLINK, error creating network link to node AITG
----Transcript of message follows----
Received: from SAIL.Stanford.EDU by hudson.dec.com with SMTP ;
Wed, 30 Nov 88 16:30:37 EST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂30-Nov-88 1407 Mail Delivery Problem
Received: from amrf (amrf.cme.nbs.gov) by SAIL.Stanford.EDU with TCP; 30 Nov 88 14:07:00 PST
Date: 30 Nov 88 16:44:40 EST
From: "SMTP MAILER" <postmaster@amrf>
Subject: Mail Delivery Problem
To: <cl-windows-mailer@sail.stanford.edu>
----Reason for mail failure follows----
Sending mail to recipient(s) meunier :
Couldn't make final delivery.
----Transcript of message follows----
Received: from SAIL.Stanford.EDU by amrf with SMTP ; Wed, 30 Nov 88 16:26:04 EST
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:14:31 PST
Received: by goldhill.com; Wed, 30 Nov 88 15:09:51 EST
Date: Wed, 30 Nov 88 15:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8811302009.AA14436@goldhill.com>
To: DALY@ibm.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Timothy Daly's message of 18 Nov 88 09:35:30 EST <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.
∂30-Nov-88 1411 Postmaster@siemens Returned mail: Service unavailable
Received: from siemens (siemens-slip.siemens.com) by SAIL.Stanford.EDU with TCP; 30 Nov 88 14:11:00 PST
Received: by siemens (5.54/1.15)
id AA01657; Wed, 30 Nov 88 17:07:44 EST
Date: Wed, 30 Nov 88 17:07:44 EST
From: Postmaster@siemens.siemens.com (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <8811302207.AA01657@siemens>
To: <CL-Windows-mailer@sail.stanford.edu>
----- Transcript of session follows -----
>>> HELO siemens
<<< 553 siemens I refuse to talk to myself
554 <metal%ztivax.siemens.com@SIEMENS.SIEMENS.COM>... Service unavailable: Bad file number
----- Unsent message follows -----
Received: by siemens (5.54/1.15)
id AA01649; Wed, 30 Nov 88 17:07:44 EST
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:14:31 PST
Received: by goldhill.com; Wed, 30 Nov 88 15:09:51 EST
Date: Wed, 30 Nov 88 15:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8811302009.AA14436@goldhill.com>
To: DALY@ibm.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Timothy Daly's message of 18 Nov 88 09:35:30 EST <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.
∂30-Nov-88 1439 Postmaster@siemens Returned mail: Service unavailable
Received: from siemens (siemens-slip.siemens.com) by SAIL.Stanford.EDU with TCP; 30 Nov 88 14:38:49 PST
Received: by siemens (5.54/1.15)
id AA01974; Wed, 30 Nov 88 17:36:19 EST
Date: Wed, 30 Nov 88 17:36:19 EST
From: Postmaster@siemens.siemens.com (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <8811302236.AA01974@siemens>
To: <CL-Windows-mailer@sail.stanford.edu>
----- Transcript of session follows -----
>>> HELO siemens
<<< 553 siemens I refuse to talk to myself
554 <metal%ztivax.siemens.com@SIEMENS.SIEMENS.COM>... Service unavailable: Bad file number
----- Unsent message follows -----
Received: by siemens (5.54/1.15)
id AA01972; Wed, 30 Nov 88 17:36:19 EST
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 12:14:31 PST
Received: by goldhill.com; Wed, 30 Nov 88 15:09:51 EST
Date: Wed, 30 Nov 88 15:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8811302009.AA14436@goldhill.com>
To: DALY@ibm.com
Cc: cl-windows@sail.stanford.edu
In-Reply-To: Timothy Daly's message of 18 Nov 88 09:35:30 EST <111888.093533.daly@ibm.com>
Subject: common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.
∂30-Nov-88 1502 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:02:01 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29392; Wed, 30 Nov 88 15:01:05 PST
Message-Id: <8811302301.AA29392@trout.nosc.mil>
Date: 30 Nov 88 14:44:08 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:35:27 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27255; Wed, 30 Nov 88 13:34:59 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:04:27 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 29 Nov 88 12:02:03 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 29 Nov 88 12:02:57 EST
Date: Tue, 29 Nov 88 12:03 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881129170307.7.BARMAR@OCCAM.THINK.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
Sun Common Lisp currently is Lucid Common Lisp. There were rumors last
year that they would be switching to Franz (who makes Allegro CL), but
this doesn't appear to have happened.
Kyoto CL is not generally considered a high-performance Lisp. Its major
feature is its portability, since it is written mostly in C and its
compiler uses C as the intermediate language. It is also well-known for
being very faithful to CLtL, implementing all and only what the book
says.
barmar
∂30-Nov-88 1503 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:02:25 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29403; Wed, 30 Nov 88 15:01:14 PST
Message-Id: <8811302301.AA29403@trout.nosc.mil>
Date: 30 Nov 88 14:44:15 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:40:40 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27441; Wed, 30 Nov 88 13:39:58 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:09:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01681g; Tue, 29 Nov 88 10:06:59 PST
Received: by bhopal id AA01309g; Tue, 29 Nov 88 10:05:50 PST
Date: Tue, 29 Nov 88 10:05:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8811291805.AA01309@bhopal>
To: bill@red.ipsa.dnd.ca
In-Reply-To: Bill Pase's message of Tue, 29 Nov 88 11:14:29 EST <8811291614.AA01479@red.ipsa.dnd.ca>
Subject: Common Lisp for SUNS
Cc: common-lisp@sail.stanford.edu
I'm not the right person to send you benchmark data on Lucid Common
Lisp, but I thought I should mention that Sun Common Lisp is Lucid
Common Lisp. (Lucid makes it, Sun sells it.)
Also, I can give some general advice about benchmarks:
(1) Be sure to note the releases being compared. For example, LCL
Version 3.0 is significantly different from LCL Version 2.1. We
added a second compiler, an ephemeral garbage collector,
multi-tasking, better inline floating point code, new interrupts,
new I/O, etc., etc.
(2) Be sure that the person who produced the benchmark values
understands the benchmarks and the lisp being tested. Proper use
of declarations and compiler settings can sometimes produce
order-of-magnitude differences. Also, for example, the use of a
feature such as ephemeral garbage collection may reflect a
decision to accept a somewhat increased running time in order to
avoid detectable pauses for GC. Turning EGC off may result in
different (usually faster) benchmark values, and might or might
not be appropriate for various applications. You need to
understand how you're going to use the lisp to know what settings
are appropriate.
(3) Ask for the *precise* techniques used to obtain the benchmarks,
including processor speed, memory size, load on the machine, etc.
I know that some of the people at Lucid have produced benchmark
figures using what we call the "low-mode" -- we run each
benchmark about 20 times or more, then use some statistics to
produce a number one could expect to be the low value obtained
in a typical set of about 3 runs. (We didn't want to just
scrounge for the lowest value, since that's not always
reproducible, yet did want to give a fair indication of the
performance possible.) I'm pretty sure the techniques used are
distributed with the benchmark numbers.
(4) If performance is critical, explain this to the vendor. For
example, Lucid is now productizing tools to reorganize your code
based on an analysis of its dynamic performance, since code and
data locality can have order-of-magnitude affects on real-life
applications. Remember that you are going to be running
applications day-to-day, and not just benchmarks. Support in
this area can be as crucial as the underlying speed of the lisp!
Happy hunting,
jlm
∂30-Nov-88 1502 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:02:04 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29398; Wed, 30 Nov 88 15:01:10 PST
Message-Id: <8811302301.AA29398@trout.nosc.mil>
Date: 30 Nov 88 14:44:11 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:37:26 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27322; Wed, 30 Nov 88 13:37:08 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:59 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 12:34:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 12:35:41 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 12:34:10 EST
Received: by joplin.think.com; Tue, 29 Nov 88 12:35:36 EST
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Message-Id: <8811291735.AA00711@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
∂30-Nov-88 1502 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:01:56 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29386; Wed, 30 Nov 88 15:01:01 PST
Message-Id: <8811302301.AA29386@trout.nosc.mil>
Date: 30 Nov 88 14:44:02 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:33:08 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27162; Wed, 30 Nov 88 13:33:00 PST
Received: from red.ipsa.dnd.ca by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:13:45 PST
Received: by red.ipsa.dnd.ca; (5.54/4.7)
id AA01479; Tue, 29 Nov 88 11:14:29 EST
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Message-Id: <8811291614.AA01479@red.ipsa.dnd.ca>
To: common-lisp@sail.stanford.edu
Subject: Common Lisp for SUNS
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
∂30-Nov-88 1506 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:03:30 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29423; Wed, 30 Nov 88 15:02:06 PST
Message-Id: <8811302302.AA29423@trout.nosc.mil>
Date: 30 Nov 88 14:44:22 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:45:23 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27650; Wed, 30 Nov 88 13:45:07 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST
Date: Tue, 29 Nov 88 13:55 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: jonl@lucid.com, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811290810.AA00624@bhopal>
Message-Id: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I agree with this (I think there's a CL cleanup that specifies this
behavior for APPEND and NCONC), and therefore the Lucid backquote
implementation is inconsistent with the definition of APPEND.
(setq d '(a . b))
`(,@d)
`(,@d . nil)
(append [,@d] 'nil)
(append d 'nil)
(append '(a . b) 'nil)
should be (a), as in your example above.
However, it was (a . b) on the version I tried - I didn't try the APPEND
case itself, so maybe in a later version both were made consistent.
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
∂30-Nov-88 1504 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:02:57 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29408; Wed, 30 Nov 88 15:01:20 PST
Message-Id: <8811302301.AA29408@trout.nosc.mil>
Date: 30 Nov 88 14:44:18 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:43:48 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27551; Wed, 30 Nov 88 13:42:58 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST
Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 29 Nov 88 10:23:29 PST (Tuesday)
Subject: Re: inconsistency in backquote spec?
From: "Larry_Masinter.PARC"@Xerox.COM
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.EDU
In-Reply-To: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28
Nov 88 18:12
Message-Id: <881129-102742-5383@Xerox>
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
Status: PASSED
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
∂30-Nov-88 1508 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:06:42 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29487; Wed, 30 Nov 88 15:05:11 PST
Message-Id: <8811302305.AA29487@trout.nosc.mil>
Date: 30 Nov 88 14:44:37 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:50:26 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27817; Wed, 30 Nov 88 13:50:11 PST
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA24518; Tue, 29 Nov 88 13:52:04 PST
Received: from frisky by franz (3.2/3.14)
id AA24713; Tue, 29 Nov 88 13:43:03 PST
Received: by frisky (3.2/3.14)
id AA02600; Tue, 29 Nov 88 13:40:54 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8811292140.AA02600@frisky>
To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase)
Cc: franz!sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST.
<8811291614.AA01479@red.ipsa.dnd.ca>
Date: Tue, 29 Nov 88 13:40:53 PST
Regarding benchmarking Lisps.
1. Declarations are important for speed, but you'll find that some
Lisps will require more specific declarations than others.
For example Sun's Lisp only supports one floating point type so declaring
something to be a 'float' is sufficient for the compiler to open code
the operation. Allegro supports two types of floats so you must declare
either 'single-float' or 'double-float.'
2. Different systems do different amounts of optimizations based on
the settings of the optimization parameters speed, safety and size.
Probably the only comparable values are for speed=3, safety=0, size=0
where each system does maximum optimization. While benchmarks
run at this value are interesting you probably aren't going to
do development with these settings since you aren't going to get
good diagnostics.
Regarding the Lisp on the Sun4.
Allegro is highly optimized for the Sun4 but you have to
add some declarations and specify that speed is important.
The comment was made that a C based Lisp on the Sun4 would
be very fast because of sun's optimizing C compiler.
While it is true that by using C you can take advantage of that
compiler, it is also true that the use of C constrains your
whole system design so you can't use the machine optimally.
I say this from many years experience programming in C parts of the
kernel of Franz Lisp. To cite two examples for the Sun4:
One of the nicest features of the sun4 (sparc) architecture
is the support the the Lisp fixnum data type (there are 'tagged'
versions of the add, subtract and compare instructions).
This allows the compiler to open code +,-,<,<=.. and so on
and if the operands happen to be fixnums (they very often are)
then the operation and fixnum tag check can go on in parallel.
This makes for fast computation in the typical case
and it is completely safe (if the tags aren't fixnum you find out
about it and perform the appropriate operation for the
actual data types).
A C based lisp can't make use of these tagged instructions.
The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asychronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp.
[The use of machine registers to hold certain values was
so important in Franz Lisp that for certain regular
architectures (e.g. vax) an incredible hack was written
by Keith Sklower to modify the assembler language coming
out of the C compiler to change certain memory references
to register references and to fix the register save masks.]
-- John Foderaro
Franz Inc.
jkf%franz.uucp@berkeley.edu
∂30-Nov-88 1508 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:05:50 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29459; Wed, 30 Nov 88 15:04:55 PST
Message-Id: <8811302304.AA29459@trout.nosc.mil>
Date: 30 Nov 88 14:44:27 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:48:41 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27742; Wed, 30 Nov 88 13:48:16 PST
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST
Received: by tut.cis.ohio-state.edu (5.59/2.881128)
id AA25824; Tue, 29 Nov 88 14:12:36 EST
Date: Tue, 29 Nov 88 14:12:36 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu>
To: barmar@think.com
Cc: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
>
>Kyoto CL is not generally considered a high-performance Lisp. Its major
>feature is its portability, since it is written mostly in C and its
>compiler uses C as the intermediate language. It is also well-known for
>being very faithful to CLtL, implementing all and only what the book
>says.
We're in the process of coming up with a decision on what lisp to get
for the University, and have been looking at Ibuki, Franz, and Envos
(and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has
been benchmarking them on Sun-3's and Sun-4's, and we've noticed that
in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind
of amazed by this, until we realised that Ibuki uses the native C
compiler, which is optimising for the SPARC architecture on the -4,
while none of the others were. This wasn't an across-the-board
speedup, just for some of the things we tried. I'd pretty much agree
with your other assessment of Kyoto CL, modulo the fact that Ibuki has
extended it somewhat (folding in the new error system, for example).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
∂30-Nov-88 1508 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:07:16 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29498; Wed, 30 Nov 88 15:05:18 PST
Message-Id: <8811302305.AA29498@trout.nosc.mil>
Date: 30 Nov 88 14:44:41 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:51:13 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27843; Wed, 30 Nov 88 13:51:06 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST
Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST
Date: Tue, 29 Nov 88 17:12:40 EST
From: gls@Think.COM
Message-Id: <8811292212.AA00825@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com,
common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
...
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item would
invalidate the examples.
--Guy
∂30-Nov-88 1512 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:07:23 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29520; Wed, 30 Nov 88 15:05:29 PST
Message-Id: <8811302305.AA29520@trout.nosc.mil>
Date: 30 Nov 88 14:44:45 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 14:03:12 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA28149; Wed, 30 Nov 88 14:03:08 PST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>, common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
∂30-Nov-88 1512 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:06:45 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA29466; Wed, 30 Nov 88 15:05:00 PST
Message-Id: <8811302305.AA29466@trout.nosc.mil>
Date: 30 Nov 88 14:44:31 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Wed Nov 30 13:49:21 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27773; Wed, 30 Nov 88 13:48:52 PST
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: gls@Think.COM, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291735.AA00711@joplin.think.com>
Message-Id: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Or, you could say that the list following a ,@ cannot be dotted.
Either way, I think, requires a minor clarification in the CL spec.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
∂30-Nov-88 1545 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1545 CL-Compiler-mailer Schedules, open issues, etc.
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 15:45:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA09713; Wed, 30 Nov 88 16:45:11 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA13170; Wed, 30 Nov 88 16:45:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811302345.AA13170@defun.utah.edu>
Date: Wed, 30 Nov 88 16:45:05 MST
Subject: Schedules, open issues, etc.
To: cl-compiler@sail.stanford.edu
The January meeting is now about a month and a half away. Since many
people (including myself) are going to be vacationing or travelling
over the holidays, we need to start getting organized a bit earlier
than normal. In particular, since we need to distribute copies of the
issues we want voted on right around the first of the year to meet the
two-week rule, we will have to resolve our internal squabbles on them
*before* we all go on vacation, not after we come back. Any issue that
doesn't have some serious progress made on it within the next few weeks
will probably be dropped or postponed indefinitely.
Following is the current list of active cl-compiler issues. The ones
I've marked "ready for release" are those that have not provoked any
discussion since the last revision of the writeup was sent around. To
avoid a repeat of what happened last time, I ask that you please look
over those issues and make sure that you've said all you're going to
say on them. If you don't have copies of the issues, I can either
handle mail requests or put them someplace FTP'able.
Finally, there is the matter of the three issues that were postponed
from the last meeting. I haven't yet heard any signs of progress from
the people who volunteered to rework these issues. In the meantime, I
have started to revise issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
myself, to include some editorial changes suggested by Pitman, specify
different handling for DEFCONSTANT, and include the CLOS defining
macros and DEFPACKAGE. As I understand it, the objections people have
with the other two issues (EVAL-WHEN-NON-TOP-LEVEL and
DEFINING-MACROS-NON-TOP-LEVEL) are more fundamental. Will one (some?
all?) of you folks who volunteered to do something about them please
try to summarize what you were planning to propose instead? Again, if
we're going to do anything about these issues it has to be happen
within the next few weeks.
ALLOW-LOCAL-INLINE
Ready for release?
COMPILE-ENVIRONMENT-CONSISTENCY
Ready for release?
COMPILE-FILE-ENVIRONMENT
Superseded by issue SYNTACTIC-ENVIRONMENT-ACCESS, unless that issue
has died.
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Waiting for alternate proposal (Pierson, Haflich, Barrett, and Perdue)
COMPILER-DIAGNOSTICS
Draft, waiting for comments from Pitman, writeup needs more work
(Loosemore)
COMPILER-LET-CONFUSION
Ready for release?
COMPILER-VERBOSITY
Pierson said he was going to submit an alternate proposal but
hasn't done so yet. Otherwise ready?
CONSTANT-ARRAY-ATTRIBUTES
Draft, under discussion (subsumed by CONSTANT-COMPILABLE-TYPES)
CONSTANT-CIRCULAR-COMPILATION
Draft, under discussion
CONSTANT-COLLAPSING
Draft, under discussion (I need to write new draft)
CONSTANT-COMPILABLE-TYPES
Draft, under discussion (Cris needs to write new draft)
CONSTANT-MODIFICATION
Draft, under discussion
DEFCONSTANT-NOT-WIRED
Still under discussion
DEFCONSTANT-SPECIAL
Ready for release (although some people disagree with it)
DEFCONSTANT-VALUE
Waiting for resolution of issue DEFINING-MACROS-NON-TOP-LEVEL
DEFINE-OPTIMIZER
Waiting for revisions (Pitman)
DEFINING-MACROS-NON-TOP-LEVEL
Waiting for alternate proposal (Pierson, Haflich, Barrett, and Perdue)
EVAL-WHEN-NON-TOP-LEVEL
Waiting for alternate proposal (Pierson, Haflich, Barrett, and Perdue)
FILE-COMPILATION
same issue as CONSTANT-COMPILABLE-TYPES
LOAD-TIME-EVAL
Ready for release?
PROCLAIM-ETC-IN-COMPILE-FILE
Waiting for resolution of related cleanup issues (DEFPACKAGE,
IN-PACKAGE-FUNCTIONALITY)
SHARP-COMMA-CONFUSION
Ready for release?
SYNTACTIC-ENVIRONMENT-ACCESS
Waiting for new writeup (Benson)
WITH-COMPILATION-UNIT
Waiting for revisions to existing proposal (Pitman)
-------
------- End undelivered message -------
∂30-Nov-88 1648 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1648 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Nov 88 16:48:51 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03120g; Wed, 30 Nov 88 16:45:55 PST
Received: by bhopal id AA04741g; Wed, 30 Nov 88 16:44:47 PST
Date: Wed, 30 Nov 88 16:44:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812010044.AA04741@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 29 Nov 88 23:52 EST <19881130045224.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
re: [fix final nits]
Ok, I'll do it. I would also like to embellish the sample code for the
do-mumble-symbols guys to be more nearly workable. What would you say to
the following for DO-SYMBOLS? [PARSE-BODY is as defined in Guy Steele's
"Clarifications" of 6-Dec-85.]
(defmacro do-symbols ((var &optional (package `*package*) result-form)
&body body)
(multiple-value-bind (body decls docstring) (parse-body body)
`(with-package-iterator (next-symbol (list ,package)
:internal :external :inherited)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(return ,result-form))
,@body)))))
-- JonL --
------- End undelivered message -------
∂30-Nov-88 1732 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1732 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Nov 88 17:31:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 500382; Wed 30-Nov-88 20:26:28 EST
Date: Wed, 30 Nov 88 20:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8812010044.AA04741@bhopal>
Message-ID: <19881201012612.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 30 Nov 88 16:44:47 PST
From: Jon L White <jonl@lucid.com>
re: [fix final nits]
Ok, I'll do it. I would also like to embellish the sample code for the
do-mumble-symbols guys to be more nearly workable. What would you say to
the following for DO-SYMBOLS? [PARSE-BODY is as defined in Guy Steele's
"Clarifications" of 6-Dec-85.]
I don't see much advantage to adding more complexity to the macro when we're
trying to show what with-package-iterator does, not how to use parse-body
(which I don't think was ever accepted into Common Lisp anyway).
If you do go down this road, you're just going to have me complaining
that your macro doesn't take an &environment argument, and things of
that ilk. I'd rather keep it simple. However, you're writing the writeup,
so do whatever you want. I only am going to complain about things that
change the definition of Common Lisp, not stylistic details of the examples.
(defmacro do-symbols ((var &optional (package `*package*) result-form)
&body body)
(multiple-value-bind (body decls docstring) (parse-body body)
`(with-package-iterator (next-symbol (list ,package)
:internal :external :inherited)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(return ,result-form))
,@body)))))
------- End undelivered message -------
∂30-Nov-88 1743 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1743 CL-Cleanup-mailer Re: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 17:43:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 17:20:07 PST
Date: Wed, 30 Nov 88 17:19 PST
From: Gregor.pa@Xerox.COM
Subject: Re: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <881130-103422-2216@Xerox>
Message-ID: <19881201011953.3.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
I continue to believe that there are two completely seperate topics:
1) Should setf be changed to have a default behavior of calling some
function whose name is derived from the "accessor. Doing this allows
one to define functions or generic functions without having to deal
with defsetf or friends.
2) If 1 is accepted, what should the name of those "setf functions" be?
One solution is so called "function specifiers". Another solution
is to have half function specifiers. I still believe the best solution
is just to use symbols everywhere even in defmethod and defgeneric forms.
I don't expect to see this be separated this way, nor do I expect that
function specs will really go away as much as they should. At this point I
promise not to argue about this at X3J13 meetings anymore. But I may sulk
about it some!
-------
------- End undelivered message -------
∂30-Nov-88 1749 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1749 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 17:48:51 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA01420; Wed, 30 Nov 88 17:51:29 PST
Received: from clam.sun.com ([129.144.42.62]) by snail.Sun.COM (4.1/SMI-4.0)
id AA24367; Wed, 30 Nov 88 17:40:29 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA15528; Wed, 30 Nov 88 17:39:53 PST
Date: Wed, 30 Nov 88 17:39:53 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812010139.AA15528@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re: Schedules, open issues, etc.
Sandra,
It would be very nice if you could put copies of proposals somewhere
FTP'able. It's hard for me to keep track even of all the replies
to my own proposals, though I think I'm succeeding there.
-Cris
------- End undelivered message -------
∂30-Nov-88 1800 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1800 CL-Compiler-mailer Re: issue IN-PACKAGE-FUNCTIONALITY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:00:33 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA03106; Wed, 30 Nov 88 18:02:13 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA24999; Wed, 30 Nov 88 17:58:24 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA15569; Wed, 30 Nov 88 17:59:13 PST
Date: Wed, 30 Nov 88 17:59:13 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812010159.AA15569@clam.sun.com>
To: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Subject: Re: issue IN-PACKAGE-FUNCTIONALITY
Cc: cl-compiler@sail.stanford.edu
> My belief is that we can fix the "problem" stated in this issue--namely
> that the current dual purpose of IN-PACKAGE reduces error checking--by
> submitting a proposal as follows:
I haven't seen traffic in reply on cl-compiler, so for what it's worth,
Masinter's proposal sounds right on the mark to me.
Of course this is a real change to the definition of Common Lisp
package handling, but something is badly needed in this area. DEFPACKAGE
looks like it would be a big help. When can we get a portable
implementation to try out, and from whom????
It would be quite nice if the ANSI standard could do without the
current requirement that LOAD must interleave resolution of symbol references
and execution of top level forms. (p.182) How about it KCL users?
Wouldn't you all like that? My impression is that
it would be within reason to eliminate this requirement if we adopt
DEFPACKAGE. Has that been considered?
-Cris
------- End undelivered message -------
∂30-Nov-88 1836 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1836 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:36:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 18:15:26 PST
Date: 30 Nov 88 18:10 PST
From: masinter.pa@Xerox.COM
Subject: Issue: STREAM-INFO (Version 6)
To: cl-cleanup@sail.stanford.edu
cc: dick@wheaties.ai.mit.edu (Richard C. Waters)
REPLY-TO: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <881130-181526-3544@Xerox>
We have not yet responded to RWK's comment, viz "Want less generic names.
eg, maybe STREAM-xxx".
What do you think about STREAM-LINE-WIDTH, STREAM-WRITE-SPACE, etc?
!
Status: DRAFT
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to
discussion)
30-Nov-88, Version 6 by Masinter (add discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS:
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative number. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns a number representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been
exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it
should
have the same line-width and width unit as the base output stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written
portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
This issue probably should have been called PRETTY-PRINT-WIDTH-SUPPORT.
Dick Waters (author of GPRINT, a portable pretty printer), originally
raised this issue.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum required to support
pretty printing into a stream which displays output using a variable width
font.
Originally the functions were defined to return integers; however, there
are some output devices (e.g., those that have arbitrary scaling
operations), for which it would be difficult to find a reasonable
least-common-denominator for line-width.
We considered an alternate proposal which goes significantly beyond what is
needed merely for pretty printing and provides primitives
LINE-DIMENSIONS, LINE-POSITION, PRINTED-DIMENSIONS, and WRITE-SPACE but
it is not included here. A key point of contention was the question of how
to handle the issue of vertical distance (where is the origin, which way
do you count, ...).
We considered requiring PRINTED-WIDTH to return two additional values:
the number of newlines that WRITE-STRING of the string would execute and
the maximum X position encountered (which might differ from the first value
if the number of newlines was non-zero).
This feature wasn't strictly necessary for pretty-printing, and so was
omitted.
Some of the draft proposals from the character committee contained some
proposed functions that were attempting to solve the same problem.
Conflicting proposals should be avoided.
------- End undelivered message -------
∂30-Nov-88 1910 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 19:10:41 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA25314; Wed, 30 Nov 88 19:09:32 PST
Date: Wed, 30 Nov 88 19:09:32 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8812010309.AA25314@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA25305; Wed, 30 Nov 88 19:09:32 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA19434; Wed, 30 Nov 88 19:09:33 PST
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:56:05 PST
Posted-Date: Wed, 30 Nov 88 18:55:38 PST
Message-Id: <8812010255.AA17146@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA17146; Wed, 30 Nov 88 18:55:41 PST
To: common-lisp@sail.stanford.edu
Subject: commonlisp types
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
∂30-Nov-88 1904 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1904 CL-Cleanup-mailer Issue: SETF-FUNCTION-VS-MACRO (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 19:04:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 18:58:33 PST
Date: 30 Nov 88 18:58 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 6)
In-reply-to: Gregor.pa's message of Wed, 30 Nov 88 17:19 PST
To: Gregor.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <881130-185833-3618@Xerox>
There are two other proposals which might also be considered on this issue:
Proposal SETF-FUNCTION-VS-MACRO:NO-SETF-FUNCTIONS
Do not change the behavior of SETF regarding the default behavior if no
setf macro has been defined. Modify the sections throughout the CLOS
specification which refer to defining methods or generic functions which
affect the behavior of SETF.
Proposal SETF-FUNCTION-VS-MACRO:USE-SYMBOL-IN-SETF-PACKAGE
The name of the SETF function associated with X is computed by
(INTERN (LET ((*PACKAGE* (FIND-PACKAGE "KEYWORD") (*PRINT-CASE* :DOWNCASE))
(FORMAT NIL "~S" X)) (FIND-PACKAGE "SETF"))
i.e., there is a package named SETF, and the SETF function for X is
computed by printing X with package qualifier and then interning the result
into the SETF package.
This only has problems if X is a symbol for which reading the printed
representation does not yield the same symbol.
------- End undelivered message -------
∂30-Nov-88 1904 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 1904 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 19:04:04 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 18:45:55 PST
Date: 30 Nov 88 18:45 PST
From: masinter.pa@Xerox.COM
Subject: Issue SYMBOL-MACROLET-SEMANTICS, Version 5
To: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: piazza%lisp.DEC@decwrl.dec.com, masinter.pa@Xerox.COM
Message-ID: <881130-184555-3598@Xerox>
I added a sentence clarifying that SYMBOL-MACROLET still
affects SETQ within its body even though it is a special form.
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
In addition, it would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
as well as DECLARE within SYMBOL-MACROLET forms.
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
------- End undelivered message -------
∂30-Nov-88 1919 Mailer@MCC.COM Message of 30-Nov-88 21:18:12
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 19:19:09 PST
Date: Wed 30 Nov 88 21:18:19-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 30-Nov-88 21:18:12
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 30 Nov 88 21:18:14-CST
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:56:05 PST
Posted-Date: Wed, 30 Nov 88 18:55:38 PST
Message-Id: <8812010255.AA17146@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA17146; Wed, 30 Nov 88 18:55:41 PST
To: common-lisp@sail.stanford.edu
Subject: commonlisp types
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
-------
∂30-Nov-88 1856 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; common-lisp-nprdc@NPRDC.ARPA; local-common-lisp@cs.glasgow.ac.uk; common-lisp@gmdzi.uucp@UUNET.UU.NET; fons@cs.vu.nl; coffee@AEROSPACE.AERO.ORG; beer@cwcais.cwru.edu
Here is how the remote host(s) replied to these mail addresses:
esmith%key.DEC@decwrl.dec.com
421 decwrl.dec.com My circuits are overloaded, try again later
latto%istg.dec@decwrl.dec.com
421 decwrl.dec.com My circuits are overloaded, try again later
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
30-Nov-88 1856 Common-Lisp-mailer commonlisp types
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:56:05 PST
Posted-Date: Wed, 30 Nov 88 18:55:38 PST
Message-Id: <8812010255.AA17146@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA17146; Wed, 30 Nov 88 18:55:41 PST
To: common-lisp@sail.stanford.edu
Subject: commonlisp types
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
------- End undelivered message -------
∂30-Nov-88 2104 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2104 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 21:04:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 21:04:06 PST
Date: 30 Nov 88 21:03 PST
From: masinter.pa@Xerox.COM
Subject: Issue: TAGBODY-CONTENTS (Version 4)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 19 Apr 88
20:15:23 PDT (really 18-Oct-88)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881130-210406-3763@Xerox>
The acceptability of the proposal might improve with some rewording, e.g.,
expressing it as a constraint on GO instead of on TAGBODY.
For example:
A TAGBODY's body consists of arbitrary data elements with arbitrary
duplications. Elements that are lists (CONSP) are evaluated in
left-to-write order. Any other elements are ignored by TAGBODY. However,
GO is only legal when given a symbol or integer. The results of executing
GO when there is more than one instance of the same (EQL) symbol or integer
at the top level of any TAGBODY are unspecified.
Thus
(TAGBODY 3.4 4.5 (print "hi there"))
is legal, although useless just as (PROGN 3.4 4.5 (print "hi there")) might
be.
------- End undelivered message -------
∂30-Nov-88 2123 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2123 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 21:23:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 21:22:26 PST
Date: 30 Nov 88 21:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 13 Oct 88 19:31 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881130-212226-3778@Xerox>
I think it might help to have the proposal say more explicitly what is
being proposed; it currently says "Permit early binding ..." which is a
very general statement.
I think what we are saying is very narrow: if you (SETF (SYMBOL-FUNCTION
'FOO) ...) after you start executing the body of the definition of FOO and
before you execute a call of FOO to itself, it is unspecified whether you
get the old definition or the new one.
In general, most implementations are required to enforce late binding for
all functions not declared inline.
This might be analogous to having
(defun foo (x) ...) expand into
(setf (symbol-function 'foo) #'(lambda (x) (declare (inline foo)) (block
foo ...)))
i.e., is a function is implicitly declared inline within its own body?
------- End undelivered message -------
∂30-Nov-88 2130 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2130 CL-Cleanup-mailer Re: Issue: TAILP-NIL (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Nov 88 21:29:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 NOV 88 21:29:16 PST
Date: 30 Nov 88 21:29 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAILP-NIL (version 3)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 19 Apr 88
19:33:14 PDT (really of 18 Oct 88)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881130-212916-3785@Xerox>
Your version 3 eliminated proposal TAILP-NIL:NIL, but retained some
references to that proposal.
If there are still some folks in favor of TAILP-NIL:NIL, we can go back to
two proposals for the ballot; I don't think that is the case, and we just
need a minor rewrite to fix the current practice, discussion sections.
------- End undelivered message -------
∂30-Nov-88 2146 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2146 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 21:45:40 PST
Date: Wed 30 Nov 88 20:30:33-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Re: Schedules, open issues, etc.
To: sandra%defun@CS.UTAH.EDU
cc: cl-compiler@SAIL.STANFORD.EDU, IIM@ECLA.USC.EDU
In-Reply-To: <8811302345.AA13170@defun.utah.edu>
Message-ID: <12450840677.23.IIM@ECLA.USC.EDU>
Re: Issue EVAL-WHEN-NON-TOP-LEVEL
Issue DEFINING-MACROS-NON-TOP-LEVEL
Regretably, due to illness and trying to meet some deadlines at work,
I haven't been able to put as much time into these as they need. I
have some rough notes that I'll ship out tommorrow, but be warned that
they are really rough.
Re: Issue (non-defining-forms-at-top-level)
It seems to me that there ought to be an issue about this, covering
things like the 7 extremely random package functions, proclaim,
provide and require (probably just a pointer to whatever cleanup
issue(s) end up covering them), compiler-let (if it survives
flushing), and maybe others that I can't think of off the top of my
head. I'll have more to say about this in the notes I'm sending out
tomorrow.
kab
-------
------- End undelivered message -------
∂30-Nov-88 2146 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2146 CL-Compiler-mailer Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 21:46:15 PST
Date: Wed 30 Nov 88 20:31:58-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12450840933.23.IIM@ECLA.USC.EDU>
My objections to the current proposal are fairly minor, and could be
easily removed. First, there are a lot of defining forms which are
missing from it. Sandra says she is planning to fix this, so that
goes away. Second, I'd like to see the removal of the "recomendation"
that (eval-when (compile) ...) be used to perform the side effects
these forms need to make, because of the current disagreements
regarding eval-when, especially when appearing at other than
top-level. I don't want to have an otherwise reasonable proposal
unnecessarily tied to a controversial one.
kab
-------
------- End undelivered message -------
∂30-Nov-88 2226 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2226 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Nov 88 22:26:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 500522; Thu 1-Dec-88 01:26:05 EST
Date: Thu, 1 Dec 88 01:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 4)
To: masinter.pa@Xerox.COM
cc: vanroggen%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <881130-210406-3763@Xerox>
Message-ID: <881201012556.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 30 Nov 88 21:03 PST
From: masinter.pa@Xerox.COM
The acceptability of the proposal might improve with some rewording, e.g.,
expressing it as a constraint on GO instead of on TAGBODY.
For example:
A TAGBODY's body consists of arbitrary data elements with arbitrary
duplications. Elements that are lists (CONSP) are evaluated in
left-to-write order. Any other elements are ignored by TAGBODY. However,
GO is only legal when given a symbol or integer. The results of executing
GO when there is more than one instance of the same (EQL) symbol or integer
at the top level of any TAGBODY are unspecified.
I'd say:
A TAGBODY's body consists of arbitrary data elements with arbitrary
duplications. Elements that are lists (CONSP) are evaluated in
left-to-right order. Any other elements are ignored by TAGBODY. However,
GO is only legal when the given tag is a symbol or integer. The results
of executing GO when there is more than one instance of the same (EQL)
tag at the top level of the innermost TAGBODY containing that tag are
unspecified.
Thus
(TAGBODY 3.4 4.5 (print "hi there"))
is legal, although useless just as (PROGN 3.4 4.5 (print "hi there")) might
be.
Personally, I like this approach.
------- End undelivered message -------
∂30-Nov-88 2241 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2241 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Nov 88 22:37:50 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 500527; Thu 1-Dec-88 01:37:54 EST
Date: Thu, 1 Dec 88 01:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881201013742.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
I know it's late to be introducing this, but I think everyone will agree
it's an issue people are likely to care about and that we should
probably address. Since it affects the language glue itself (including
variable access, function calling, and CLOS), I'm sending it to
CL-Cleanup instead of some more specialized list.
However, since this isn't likely to be non-controversial enough to make
Masinter's upcoming mail ballot, please let's not waste a lot of time
discussing this until after the pre-ballot rush. I just wanted to get it
on the books for people to contemplate...
-kmp
-----
Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
References: 5.1.2 Variables (CLtL pp55-56),
Slots (88-002R, p1-10)
Category: CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL does not specify what happens if you attempt to call a named function
which is in fact undefined. In most implementations, it would be devastating to
actually jump to code which you had not verified to be a function, so this error
should be easily caught -- yet, CLtL does not guarantee that an error will be
signalled even in the safest, least fast OPTIMIZE settings.
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
signals an error."
CLOS and CLtL are not in agreement on their treatment of unbound variables.
CLtL is very weak in that it guarantees no support for reliably detecting
and signalling an error when the error situation occurs, even in the safest,
least fast OPTIMIZE setting.
CLOS is very strong in that it forces detection of the error in all
situations -- even in the fastest, least safe OPTIMIZE setting.
The disparate positions for treatment of variables and slots should be
reconciled, either by finding a compromise or by justifying the apparent
inconsistency. The final story should explain function references as well.
Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
Define that reading an undefined function, an unbound variable, or
an unbound slot must be detected in the highest safety setting,
but the effect is undefined in any other safety setting. That is,
- Reading an undefined function should signal an error.
- Reading an an unbound variable should signal an error.
- Reading an unbound slot should invoke the function SLOT-UNBOUND.
By ``reading an undefined function'' in the above, we mean to
include both references to the function using the FUNCTION
special form, such as F in (FUNCTION F) and references to the
function in a call, such as F in (F X).
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
Specify that the type of error signalled when an undefined function
is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
UNDEFINED-FUNCTION condition is initialized to the name of the
offending function.
Specify that the type of error signalled when a unbound variable
is detected is UNBOUND-VARIABLE, and that the NAME slot of the
UNBOUND-VARIABLE condition is initialized to the name of the
offending variable.
Introduce a new condition type, UNBOUND-SLOT, which inherits from
CELL-ERROR. This new type has an additional slot, INSTANCE, which
can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
Specify that the type of error signalled by the default primary
method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
and that the NAME slot of the UNBOUND-SLOT condition is initialized
to the name of the offending variable, and that the INSTANCE slot
of the UNBOUND-SLOT condition is initialized to the offending instance.
Test Case:
(PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
(DEFUN FOO () X)
(FOO)
>>Error: The variable X is not bound.
...
Rationale:
This makes it easier to treat slots like variables.
This makes it possible to better rely on an unbound variable error being
signalled when one has occurred.
This makes it possible to compile out useless error checking in CLOS
code where the code is debugged and the checking is redundant.
For the case of undefined functions, blindly jumping to an undefined
function is an incredibly dangerous thing to do. Every implementation
should guarantee at least some way to get error checking of undefined
functions.
Current Practice:
Until recently, Symbolics Cloe did not ever signal an error on unbound
variable, even in the safest case. The excuse was that this was a CLtL
didn't require it, but it was sometimes an impediment to debugging.
Some benchmarks for Symbolics Cloe (which currently only claims to
implement New Flavors, not CLOS) could be faster if checking for unbound
instance variables could be optimized away.
Symbolics Genera doesn't care about safety issues in variable access
because the check can be done by microcode.
Cost to Implementors:
This change does not force a change to any current implementation, except
those which do not yet signal unbound variable or undefined function errors
even in the safest setting.
Cost to Users:
This checking might slow down some code which is written for the safest
setting yet does not need this check.
Any implementation-specific code which depended on these references not
signalling would be broken. Such code was not portable, of course.
Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
settings would be broken. The amount of such code at this point is likely
to be little or none. If such cases did exist, local or global changes to
safety settings would correct the problem (at some cost in speed).
Cost of Non-Adoption:
Some important error checking would not occur.
Some important optimizations could not be done.
The language would seem internally less consistent.
Benefits:
The costs of non-adoption would be avoided.
Aesthetics:
This would regularize things a little.
Discussion:
Pitman thinks this would be a good idea.
------- End undelivered message -------
∂30-Nov-88 2254 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2254 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Nov 88 22:53:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 500534; Thu 1-Dec-88 01:53:17 EST
Date: Thu, 1 Dec 88 01:53 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: Masinter.pa@Xerox.COM
cc: Dick@Wheaties.AI.MIT.EDU, CL-Cleanup@sail.stanford.edu
In-Reply-To: <881130-181526-3544@Xerox>
Message-ID: <881201015306.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 30 Nov 88 18:10 PST
From: masinter.pa@Xerox.COM
We have not yet responded to RWK's comment, viz "Want less generic names.
eg, maybe STREAM-xxx".
What do you think about STREAM-LINE-WIDTH, STREAM-WRITE-SPACE, etc?
I don't really like the STREAM-xxx but can live with it as a compromise if it
will get this thing passed.
STREAM-LINE-WIDTH is ok with me.
STREAM-WRITE-SPACE seems redundant since WRITE is already a stream operation.
I guess I'd prefer just WRITE-SPACE.
LINE-POSITION could be STREAM-LINE-POSITION, conforming to the STREAM-xxx idea.
PRINTED-WIDTH is misleadingly named (in my opinion) because the function PRINT
is not involved. Since I think STREAM-WRITTEN-WIDTH looks a little weird,
I guess I'd like something like STREAM-STRING-WIDTH better.
------- End undelivered message -------
∂30-Nov-88 2317 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2317 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Nov 88 23:17:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 500541; Thu 1-Dec-88 02:17:20 EST
Date: Thu, 1 Dec 88 02:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: jonl@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8811300617.AA03229@bhopal>
Message-ID: <881201021710.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 22:17:59 PST
From: Jon L White <jonl@lucid.com>
... I'd like to see a section in the spec that concerns these
"destructive" operations to say explicity that it is perfectly
all right for them _not_ to destroy anything but instead to
"cons" new results. ...
I talked to a Lucid user about this tonight. That user said that your
implementation does a copy for SORT (for example) and that your GC
doesn't really keep up. His claim was that your implementation would
be faster if you did side-effect. I won't be surprised if you tell
me this problem has been fixed, but in any case it raises the point
that this is a situation which could easily arise.
I'd certainly be willing to stipulate in the proposal that there may be
circumstances in which new results are consed instead, so that users
would know they had to do the SETQ in all cases, but...
I'm not really psyched about it saying anywhere that it's "perfectly
all right". It's "all right under some special circumstances", which
may have the same legal weight. But I'd like to at least have some
verbiage in there that says that the intent is that copying would
occur only if it's really true that copying is more efficient. The
metric I would expect is that if you sit in a loop, repeatedly sorting
a list by #'< and #'> (so that it keeps changing), if a copying
implementation stays ahead of a non-copying implementation (that is,
the sum of copying + GC is still faster than copying), then it's
really ok.
I don't want implementors to think that it's acceptable to do
(DEFUN APPEND (&REST X) ...hair...)
(SETF #'NCONC #'APPEND)
just because they are either too lazy to write NCONC or have some
personal crusade to wage against side-effects.
I think the reason someone calls NCONC rather than APPEND is to get
something efficient, for a price. Even if you don't modify, they've
still paid the price because they have to be afraid you've modified,
so they're entitled to know they got something for this price.
I don't propose putting all of the above in the proposal. I just
wanted to make my opinion clear. I propose changing the proposal by...
- striking the three or so places that it explicitly reminds you
to use SETQ in case a side-effect doesn't occur
- adding some general purpose verbiage that says something like
that the purpose of these operators is to provide you the most
efficient algorithm, and that in some situations or some
implementations, there may be some reasons why the most
efficient thing is to copy rather than to side-effect. As such
none of these operators are actually required to side-effect,
but the user should assume that, whatever the implementation, it
will have speed competitive with or surpassing a side-effecting
implementation.
Also, GSB points out that SORT, STABLE-SORT, and MERGE are conspicuously
absent from the list. They should be added in as well.
I'll be happy to make the changes if we can agree up front that
they sound like the right thing.
Does this sound ok?
------- End undelivered message -------
∂30-Nov-88 2354 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
30-Nov-88 2354 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 30 Nov 88 23:54:12 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 246302; Thu 1-Dec-88 02:11:20 EST
Date: Thu, 1 Dec 88 02:11 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: sandra%defun@cs.utah.edu, Gray@DSG.csc.ti.com
cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: <8811300234.AA12495@defun.utah.edu>
Message-ID: <19881201071110.2.GSB@GANG-GANG.SCRC.Symbolics.COM>
I believe that one of the reasons that there is a problem in sorting out
the behavior of various orders of proclamations and setqs is that you
are attempting to fill a hole which common lisp has left in the
language. What is missing is a clear and atomic statement of a name
(variable), its attributes (special, immutability of the variable,
whether it should be wired, its type), and its initialization. Because
the Common Lisp-provided mechanisms for defining the various attributes
of a variable are done by separate forms, lots of effort has gone into
divining the subtleties of what happens when the different components
that go into a definition are done at different times and different
orders. This isn't new to this particular discussion; for instance, a
clarification was needed for INLINE.
What this implies is that for any kind of global statement about a
variable, there should be a definitional form (e.g. DEFVAR, DEFCONSTANT)
which contains all of the necessary declarative and initialization
information. This doesn't preclude a proclamation; the definition form
however gives the implementation the latitude to do some checking for
you, which would be prohibitive to put on arbitrary SETQs of free
variables at runtime. For instance, warn or query when a DEFVAR of a
particular variable being repeated by a different file than before;
query to permit or deny changing the value of a constant.
If *I* were a compiler and I came across the sequence
(defmacro defconst (variable value)
`(progn
(eval-when (eval compile load)
(proclaim '(constant ,variable)))
(makunbound ',variable)
(setq ,variable ,value)
',variable))
(defconst memory-size (determine-memory-size))
I would complain violently about that setq of an unalterable value and
that blatant makunbound. It probably IS better to cleanly expose the
initialization mechanism for variables. Consider, for instance
DEFINE-VARIABLE such that:
(defmacro defvar (name &optional (initial-value nil initp) documentation)
`(define-variable
',name
'special
,@(and initp `(:initial-value
;;Don't compute it unless we will need it.
,(if (boundp ',name) ,name ,initial-value)))
:documentation ',documentation
))
(defmacro defparameter (name initial-value &optional documentation)
`(define-variable
',name
'special
:initial-value ,initial-value
:documentation ',documentation))
(defmacro defconstant (name initial-value &optional documentation)
`(define-variable
',name
'constant
:permit-wiring t ;Perhaps a more formal-sounding name should be used
:initial-value ,initial-value
:documentation ',documentation))
(defmacro defparameter-unalterable (name initial-value &optional doc)
`(define-variable
',name
'constant
:permit-wiring nil
:initial-value ,initial-value
:documentation ',documentation))
DEFINE-VARIABLE would be recognized by the compiler much the way
PROCLAIM is. Having the initial value there permits the compiler to
examine it to decide on whether to wire it in in those cases where that
is permissible. It also obviates the question of when the SETQ of an
allegedly unalterable variable is permissible, and isolates where the
implementation-dependent bypass of that check occurs. An implementation
could provide consistency checking, redefinition checking, etc.
A special case of this might be
(define-variable 'foo 'constant :incremental-initialization <new-value>)
which is basically a way of saying "setq the variable for me and don't
barf because I said it was unalterable". (Barfing or warning would be
appropriate though if wiring was permitted.) This would satisfy the
problem of incremental or distributed computation of an unalterable
value.
The above is sort of a straw-man proposal; I have no particular
attachment to any of the syntax or names used, especially with respect
to the last special case. Probably a better argument list is
(name
&key constant ;NIL implies just SPECIAL, T unalterable.
permit-wiring ;Illegal if CONSTANT is NIL
(initial-value nil initial-value-p)
(documentation nil set-doc-p)
...)
----------------
Some different but related nits I have...
A CONSTANT proclamation which results in a subtly different result from
what DEFCONSTANT gives will result in an Ergonomically Inferior Lisp.
One way around that is to modify the declaration slightly to have syntax
(CONSTANT name &KEY (permit-wiring T))
which would then surprise everyone as being the first declaration with
&key arguments.
Same goes for use of the name DEFCONST.
------- End undelivered message -------
∂01-Dec-88 0029 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0029 CL-Compiler-mailer Re: issue DEFCONSTANT-SPECIAL, version 2
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 1 Dec 88 00:28:53 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 246322; Thu 1-Dec-88 03:28:49 EST
Date: Thu, 1 Dec 88 03:28 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: issue DEFCONSTANT-SPECIAL, version 2
To: cl-compiler@sail.stanford.edu
Message-ID: <19881201082844.3.GSB@GANG-GANG.SCRC.Symbolics.COM>
My belief has always been that a variable defined by DEFCONSTANT was
declared special with additional assertions of its constantness; i never
bothered to think about the strange wording on page 69 which can imply
otherwise. In any event, there certainly wasn't any intent at the time
that was written for anything but the global special value of the
variable to be used. SYMBOL-VALUE should work on it, for instance.
Until such a time as PROCLAIM-LEXICAL is adopted, it seems premature to
specify that the value of a defconstant is stored anywhere else.
Certainly this could not be considered a "clarification". I'm not at
all sure where i would find the global lexical value of things in some
implementations.
Perhaps a case could be made from the same ambiguous wording that while
a defconstant's value is stored as a global special value, defconstant
fails to produce a pervasive special declaration and as a consequence
one can blithely perform new lexical bindings of the same name... But
even to do this seems to require a weird mental contortion about the
relationship of the scoping of the defconstant's value, specialness, and
constantness.
I would be willing to say that the wording which implies the possibility
of a lexical binding is a fluke and should be removed as a
clarification. Any other change would amount to changing the language,
and should wait on or come under PROCLAIM-LEXICAL.
I was going to say something about how I'm not making an argument about
whether one should be able to bind constants, only what the Book says or
meant to say, when i realized that I had taken a lisp which tried to be
common lisp before common lisp was, in which T and NIL were ordinary
symbols and #T and () were truth and falseness, and fixed it to be
common-lisp compatible. This discussion doesn't belong here anyway.
------- End undelivered message -------
∂01-Dec-88 0042 Mailer-Daemon@Sun.COM Returned mail: Remote protocol error
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 00:42:48 PST
Received: by Sun.COM (4.1/SMI-4.0)
id AA04446; Thu, 1 Dec 88 00:35:00 PST
Date: Thu, 1 Dec 88 00:35:00 PST
From: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8812010835.AA04446@Sun.COM>
To: <CL-Compiler-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
Connected to clam:
>>> MAIL From:<CL-Compiler-mailer@SAIL.Stanford.EDU>
<<< 554 rewrite: expansion too long
>>> QUIT
<<< 554 rewrite: expansion too long
554 <clcomp@CLAM.SUN.COM>... Remote protocol error
----- Unsent message follows -----
Received: from SAIL.Stanford.EDU by Sun.COM (4.1/SMI-4.0)
id AA04427; Thu, 1 Dec 88 00:35:00 PST
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 1 Dec 88 00:28:53 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 246322; Thu 1-Dec-88 03:28:49 EST
Date: Thu, 1 Dec 88 03:28 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: issue DEFCONSTANT-SPECIAL, version 2
To: cl-compiler@sail.stanford.edu
Message-Id: <19881201082844.3.GSB@GANG-GANG.SCRC.Symbolics.COM>
My belief has always been that a variable defined by DEFCONSTANT was
declared special with additional assertions of its constantness; i never
bothered to think about the strange wording on page 69 which can imply
otherwise. In any event, there certainly wasn't any intent at the time
that was written for anything but the global special value of the
variable to be used. SYMBOL-VALUE should work on it, for instance.
Until such a time as PROCLAIM-LEXICAL is adopted, it seems premature to
specify that the value of a defconstant is stored anywhere else.
Certainly this could not be considered a "clarification". I'm not at
all sure where i would find the global lexical value of things in some
implementations.
Perhaps a case could be made from the same ambiguous wording that while
a defconstant's value is stored as a global special value, defconstant
fails to produce a pervasive special declaration and as a consequence
one can blithely perform new lexical bindings of the same name... But
even to do this seems to require a weird mental contortion about the
relationship of the scoping of the defconstant's value, specialness, and
constantness.
I would be willing to say that the wording which implies the possibility
of a lexical binding is a fluke and should be removed as a
clarification. Any other change would amount to changing the language,
and should wait on or come under PROCLAIM-LEXICAL.
I was going to say something about how I'm not making an argument about
whether one should be able to bind constants, only what the Book says or
meant to say, when i realized that I had taken a lisp which tried to be
common lisp before common lisp was, in which T and NIL were ordinary
symbols and #T and () were truth and falseness, and fixed it to be
common-lisp compatible. This discussion doesn't belong here anyway.
∂01-Dec-88 0434 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0434 CL-Compiler-mailer Re: Objects in quoted constants
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 1 Dec 88 04:31:14 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05388; 30 Nov 88 18:39 GMT
Date: Wed, 30 Nov 88 18:42:19 GMT
Message-Id: <1985.8811301842@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Objects in quoted constants
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
RWK%f.ila.dialnet.symbolics.com@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Tue, 29 Nov 88 22:43:50 PST
Cc: cperdue@sun.com, cl-compiler@sail.stanford.edu
> Quite true. But does one bad bug deserve another?
No, but there's something to be said for (1) consistency and
(2) abstraction. Nonetheless, I don't mind if more attributes
can be dumped provided that we don't go beyond things that could
reasonably be part of printed representations.
> Jim MacDonald was going to submit a point of view that claims the
> PRINT/READ scenario is _not_ an appropriate model for dump/load,
> but rather the guideing principle should be preservation of at least
> the components that the "MAKE" function has as arguments.
Why wouldn't this same principle apply to PRINT and READ?
> PRINT/READ preservation is appropriate for C-like languages;
> Constructor-function argument preservation is appropriate for Lisp.
I don't know why you say this, unless "C-like" is supposed to be merely
a synonym for "bad", because it doesn't sound like a true statement
about C at all. C does not provide any way to print and read structures
or arrays as printed representations: that is something Lisp does.
A C program can write out the actual bytes contained in the struct
or array and read them back in, but that's not the same thing.
The whole idea that most objects have printed representations is
strongly associated with Lisp and not with "C-like" languages.
-- Jeff
------- End undelivered message -------
∂01-Dec-88 0712 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0712 CL-Compiler-mailer Re: Issue: FILE-COMPILATION (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 1 Dec 88 07:11:22 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05753; 30 Nov 88 19:33 GMT
Date: Wed, 30 Nov 88 19:35:44 GMT
Message-Id: <2124.8811301935@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: FILE-COMPILATION (Version 1)
To: sandra <@cs.utah.edu:sandra@defun>,
Kent M Pitman <KMP@scrc-stony-brook.arpa>
In-Reply-To: Sandra J Loosemore's message of Mon, 28 Nov 88 13:14:28 MST
Cc: CL-Compiler@sail.stanford.edu
> Actually, I don't see much in this proposal that hasn't already been
> addressed by the latest proposal on issue CONSTANT-COMPILABLE-TYPES.
> It seems to me like the other differences between your proposal and
> Cris's (handling of uninterned symbols and readtables, for example)
> could be ironed out in the context of the existing issue. I don't
> think it's necessary (or even a good idea) to open an entirely new
> issue just because you don't like the existing writeup.
Well, Kent is proposing merging *several* issues and assorted
other topics. I find it very hard to follow seven or so different
subjects about more or less the same thing. I don't particularly
care whether Kent does this or someone else, but I would like to
see some simplification.
-- Jeff
------- End undelivered message -------
∂01-Dec-88 0715 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0715 CL-Compiler-mailer Re: issue DEFCONSTANT-NOT-WIRED, version 5
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 1 Dec 88 07:15:20 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05592; 30 Nov 88 19:13 GMT
Date: Wed, 30 Nov 88 19:15:49 GMT
Message-Id: <2074.8811301915@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue DEFCONSTANT-NOT-WIRED, version 5
To: David N Gray <Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK>,
sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: David N Gray's message of Tue, 29 Nov 88 09:17:18 CST
Cc: cl-compiler@sail.stanford.edu
>
> I'm still having trouble with this approach. First, our compiler would
> issue a warning on the SETQ that MEMORY-SIZE is not a defined variable
> and is being assumed to be special. Is such a warning not appropriate?
> It is very useful for catching spelling errors that could go unnoticed
> otherwise.
Opinions differ on whether the warning is desirable. The problem is
that the warning goes away only when I proclaim the variable special,
and I may not want to do that. It's sometimes desirable to have global
variables that are not names-special-everywhere. See PROCLAIM-LEXICAL.
------- End undelivered message -------
∂01-Dec-88 0826 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:26:42 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA06126; Thu, 1 Dec 88 08:25:40 PST
Date: Thu, 1 Dec 88 08:25:40 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8812011625.AA06126@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA06123; Thu, 1 Dec 88 08:25:40 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA26196; Thu, 1 Dec 88 08:25:41 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:06:41 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 1 Dec 88 10:48:06 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 1 Dec 88 11:04:43 EST
Date: Thu, 1 Dec 88 11:04 EST
From: Barry Margolin <barmar@Think.COM>
Subject: commonlisp types
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812010255.AA17146@vaxa.isi.edu>
Message-Id: <19881201160446.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
Since CLtL doesn't say that TYPEP must signal an error if the type
specifier is invalid, it currently "is an error" if the type specifier
is not a valid type specifer other than (FUNCTION ...) or (VALUES ...).
I don't think there has been any suggestion within X3J13 to change this.
In general, Common Lisp tends not to require implementations to do lots
of this kind of checking; at high safety optimization levels it is
informally encouraged, but not required.
Actually, in this particular case, I don't think that requiring an error
to be signalled would be too bad. TYPEP must already do a significant
amount of work to decode the type specifier, so it probably knows when
the type specifier is invalid, and signalling an error would be pretty
easy. However, putting this requirement into the CL standard would be
an incompatible change to the language definition, with only minor gain,
and I think it is kind of late for it now (we're not very far from
trying to get a draft finished).
As for your suggestion about (SATISFIES ...), I personally think that is
a bad idea. TYPEP shouldn't silently hide bugs in the programmer's
predicate. The above example should have been written as
(typep nil '(and number (satisfies zerop)))
barmar
∂01-Dec-88 0828 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0828 CL-Compiler-mailer Re: CONSTANT-COMPILABLE-TYPES
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:28:34 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA26231; Thu, 1 Dec 88 08:27:42 PST
Received: from frisky by franz (3.2/3.14)
id AA01529; Thu, 1 Dec 88 08:25:33 PST
Received: by frisky (3.2/3.14)
id AA07652; Thu, 1 Dec 88 08:23:23 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8812011623.AA07652@frisky>
To: franz!sun!cperdue (Cris Perdue)
Cc: franz!sail.stanford.edu!cl-compiler
Subject: Re: CONSTANT-COMPILABLE-TYPES
In-Reply-To: Your message of Wed, 30 Nov 88 12:50:30 PST.
<8811302050.AA14971@clam.sun.com>
Date: Thu, 01 Dec 88 08:23:22 PST
>> Also, it wasn't clear to me whether
>> retaining EQ'ness across a file would solve a significant set
>> of problems for people.
We put this feature in long ago when PCL required it (PCL would
create gensym-named functions and unless you retained eq'ness of
gensymed symbols throughout a compilation these gensym-named functions
were uncallable). PCL may no longer require this but I recall other
users asking if we had this feature. I think that this is (yet
another) case where if even one vendor supports this feature then
people come to depend upon it and it becomes a defacto requirement.
Since most of the Common Lisps around these days supported the early
version of PCL, I suspect that most Lisps already retain eq'ness of
gensymed symbols.
------- End undelivered message -------
∂01-Dec-88 0840 Mailer@MCC.COM Message of 1-Dec-88 10:37:52
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:40:04 PST
Date: Thu 1 Dec 88 10:38:00-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 1-Dec-88 10:37:52
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 1 Dec 88 10:37:54-CST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:06:41 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 1 Dec 88 10:48:06 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 1 Dec 88 11:04:43 EST
Date: Thu, 1 Dec 88 11:04 EST
From: Barry Margolin <barmar@Think.COM>
Subject: commonlisp types
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812010255.AA17146@vaxa.isi.edu>
Message-Id: <19881201160446.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
Since CLtL doesn't say that TYPEP must signal an error if the type
specifier is invalid, it currently "is an error" if the type specifier
is not a valid type specifer other than (FUNCTION ...) or (VALUES ...).
I don't think there has been any suggestion within X3J13 to change this.
In general, Common Lisp tends not to require implementations to do lots
of this kind of checking; at high safety optimization levels it is
informally encouraged, but not required.
Actually, in this particular case, I don't think that requiring an error
to be signalled would be too bad. TYPEP must already do a significant
amount of work to decode the type specifier, so it probably knows when
the type specifier is invalid, and signalling an error would be pretty
easy. However, putting this requirement into the CL standard would be
an incompatible change to the language definition, with only minor gain,
and I think it is kind of late for it now (we're not very far from
trying to get a draft finished).
As for your suggestion about (SATISFIES ...), I personally think that is
a bad idea. TYPEP shouldn't silently hide bugs in the programmer's
predicate. The above example should have been written as
(typep nil '(and number (satisfies zerop)))
barmar
-------
∂01-Dec-88 0857 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0857 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:56:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA28693; Thu, 1 Dec 88 09:54:14 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA13664; Thu, 1 Dec 88 09:53:11 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812011653.AA13664@defun.utah.edu>
Date: Thu, 1 Dec 88 09:53:09 MST
Subject: Re: Schedules, open issues, etc.
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Wed, 30 Nov 88 17:39:53 PST
OK, the issues that were marked "ready for release" are available for
anonymous FTP on cs.utah.edu (128.110.4.21). Look in the directory
pub/cl-compiler.
If there is some other issue you want, you'll have to send me e-mail.
(I don't have enough disk quota on cs to put copies of everything out
there.)
-Sandra
-------
------- End undelivered message -------
∂01-Dec-88 0807 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; local-common-lisp@cs.glasgow.ac.uk; common-lisp@gmdzi.uucp@UUNET.UU.NET
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
01-Dec-88 0807 Common-Lisp-mailer commonlisp types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:06:41 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 1 Dec 88 10:48:06 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 1 Dec 88 11:04:43 EST
Date: Thu, 1 Dec 88 11:04 EST
From: Barry Margolin <barmar@Think.COM>
Subject: commonlisp types
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812010255.AA17146@vaxa.isi.edu>
Message-Id: <19881201160446.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
Since CLtL doesn't say that TYPEP must signal an error if the type
specifier is invalid, it currently "is an error" if the type specifier
is not a valid type specifer other than (FUNCTION ...) or (VALUES ...).
I don't think there has been any suggestion within X3J13 to change this.
In general, Common Lisp tends not to require implementations to do lots
of this kind of checking; at high safety optimization levels it is
informally encouraged, but not required.
Actually, in this particular case, I don't think that requiring an error
to be signalled would be too bad. TYPEP must already do a significant
amount of work to decode the type specifier, so it probably knows when
the type specifier is invalid, and signalling an error would be pretty
easy. However, putting this requirement into the CL standard would be
an incompatible change to the language definition, with only minor gain,
and I think it is kind of late for it now (we're not very far from
trying to get a draft finished).
As for your suggestion about (SATISFIES ...), I personally think that is
a bad idea. TYPEP shouldn't silently hide bugs in the programmer's
predicate. The above example should have been written as
(typep nil '(and number (satisfies zerop)))
barmar
------- End undelivered message -------
∂01-Dec-88 0936 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0936 CL-Compiler-mailer Re: Issue DEFCONSTANT-NOT-WIRED, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Dec 88 09:36:07 PST
Received: by ti.com id AA01278; Thu, 1 Dec 88 11:34:30 CST
Received: from Kelvin by tilde id AA22208; Thu, 1 Dec 88 11:30:51 CST
Message-Id: <2805989569-4329935@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 1 Dec 88 11:32:49 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: Issue DEFCONSTANT-NOT-WIRED, version 5
In-Reply-To: Msg of Wed, 30 Nov 88 07:38 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
> Seems to me that the question of what operations or forms in loaded files
> can be done more than once (i.e. upon reloading) without signalling errors
> really deserves to be a totally separate issue. Perhaps cl-cleanup should
> consider addressing it. Such is not limited to setting of constants; it
> also affects function definitions, DEFSTRUCTs, CLOS, and lots of other things.
> So I wouldn't let the file-reloading problem affect the deliberations on
> how a SETQ of a constant is to be done.
I don't think this is really the same. On the one hand you have a
question about what warnings an implementation might choose to produce,
whereas on the other hand is a case where the proposed specification
would make it an error to reload the file; that is a situation that we
have not had before.
------- End undelivered message -------
∂01-Dec-88 0956 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 0956 CL-Compiler-mailer Re: Objects in quoted constants
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 09:56:00 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA07309; Thu, 1 Dec 88 09:56:58 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA08568; Thu, 1 Dec 88 09:53:31 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA16422; Thu, 1 Dec 88 09:54:25 PST
Date: Thu, 1 Dec 88 09:54:25 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812011754.AA16422@clam.sun.com>
To: RWK%f.ila.dialnet@symbolics.com,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, jonl@lucid.com
Subject: Re: Objects in quoted constants
Cc: cl-compiler@sail.stanford.edu
> . . . Nonetheless, I don't mind if more attributes
> can be dumped provided that we don't go beyond things that could
> reasonably be part of printed representations.
This is quite acceptable to me also.
On one hand, the input so far from Lucid,
Franz, Coral, Texas Instruments, and the implementation discussed
by Kerns, says to me that most Lisp vendors see demand for a fairly
high level of capability to handle most types and "circular" structures.
PRINT does not do enough now, and even has an incompatibility with
handling (DEFSTRUCT) structures as needed, BUT
On the other hand, I'm sure we can make compilable constants printable
(in the spirit of PRINT), and if we wish, we can extend Common Lisp
printing so that all compilable constants can be readably dumped in the
style of PRINT, and with few modifications to the PRINTed form of
things that PRINT reREADably today.
I'm determined to choose goals for handling of compiled constants
first. If someone else has the energy to propose exactly how
to extend Common Lisp printing to handle all compilable constants,
that would be excellent. (By the way, I really expect that it
will be truly reasonable to extend any given implementation to handle whatever
class of constants we decide on. Handling circularity appears to be
the biggest problem, and most implementations already can handle that.)
------- End undelivered message -------
∂01-Dec-88 1001 Mailer@MCC.COM Message of 28-Nov-88 10:59:30
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 10:01:30 PST
Date: Thu 1 Dec 88 11:59:34-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Message of 28-Nov-88 10:59:30
Message undeliverable and dequeued after 3 days:
CL-Object-Oriented-Programming@Hal.CAD.MCC.com: Cannot connect to host
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 28 Nov 88 10:59:32-CST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
-------
∂01-Dec-88 1047 MAILER-DAEMON@decwrl.dec.com Returned mail: Cannot send message for 3 days
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Dec 88 10:47:00 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for CL-Object-Oriented-Programming-mailer@sail.stanford.edu; id AB21005; Thu, 1 Dec 88 10:46:18 PST
Date: Thu, 1 Dec 88 10:46:18 PST
From: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8812011846.AB21005@decwrl.dec.com>
To: <CL-Object-Oriented-Programming-mailer@sail.stanford.edu>
----- Transcript of session follows -----
mail11: connect to bach failed, Host is unreachable
----- Unsent message follows -----
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for bach::robbins; id AA05417; Mon, 28 Nov 88 08:50:10 PST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂01-Dec-88 1047 MAILER-DAEMON@decwrl.dec.com Returned mail: Cannot send message for 3 days
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Dec 88 10:47:11 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for CL-Object-Oriented-Programming-mailer@sail.stanford.edu; id AB21005; Thu, 1 Dec 88 10:46:28 PST
Date: Thu, 1 Dec 88 10:46:28 PST
From: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8812011846.AB21005@decwrl.dec.com>
To: <CL-Object-Oriented-Programming-mailer@sail.stanford.edu>
----- Transcript of session follows -----
----- Unsent message follows -----
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for bach::savignano; id AA05442; Mon, 28 Nov 88 08:50:31 PST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂01-Dec-88 1047 MAILER-DAEMON@decwrl.dec.com Returned mail: Cannot send message for 3 days
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Dec 88 10:47:25 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for CL-Object-Oriented-Programming-mailer@sail.stanford.edu; id AB21005; Thu, 1 Dec 88 10:46:41 PST
Date: Thu, 1 Dec 88 10:46:41 PST
From: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8812011846.AB21005@decwrl.dec.com>
To: <CL-Object-Oriented-Programming-mailer@sail.stanford.edu>
----- Transcript of session follows -----
----- Unsent message follows -----
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for bach::vanroggen; id AA05476; Mon, 28 Nov 88 08:50:40 PST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88 08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Circular structures are fully supported in the list
LISP
I am describing. I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly. I suspect all would agree it's the right thing, but I
don't know about willingness to comply.
...
The mystery lisp does not currently coalesce non-EQ constants.
Correction: I mean to say non-EQL constants. CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.
∂01-Dec-88 1106 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1106 CL-Compiler-mailer Objects in quoted constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Dec 88 11:03:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03634g; Thu, 1 Dec 88 11:01:19 PST
Received: by bhopal id AA01066g; Thu, 1 Dec 88 11:00:13 PST
Date: Thu, 1 Dec 88 11:00:13 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812011900.AA01066@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: @sail.stanford.edu:jonl@lucid.com,
RWK%f.ila.dialnet.symbolics.com@NSS.Cs.Ucl.AC.UK, cperdue@sun.com,
cl-compiler@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Wed, 30 Nov 88 18:42:19 GMT <1985.8811301842@subnode.aiai.ed.ac.uk>
Subject: Objects in quoted constants
> > Jim MacDonald was going to submit a point of view that claims the
McDonald (come on JonL, we've worked together 4 years!)
> > PRINT/READ scenario is _not_ an appropriate model for dump/load,
> > but rather the guideing principle should be preservation of at least
> > the components that the "MAKE" function has as arguments.
>
> Why wouldn't this same principle apply to PRINT and READ?
Because people read files created for printing/reading, but no
rational human ever looks at the files created for dumping/loading.
Hence you can put all sorts of ugly obscure syntax into dump/load and
no one will be offended or complain that an optional argument should
be a keyword argument, etc. (You can even put in all sorts of obscure
directives that say where in memory things should go, etc., without
worrying about what such intervention does to the intelligibilty of
the data.)
In the fullness of time print/read *should* preserve all the "make"
arguments, but I wouldn't hold my breath for people to agree on
formats.
jlm
------- End undelivered message -------
∂01-Dec-88 1108 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1108 CL-Cleanup-mailer Issue: TAILP-NIL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Dec 88 11:07:54 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 500797; Thu 1-Dec-88 14:07:46 EST
Date: Thu, 1 Dec 88 14:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881201140733.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok, I updated this per discussion.
- Added a paragraph to Problem Description acknowledging JonL's claim
that this is not only about what is a sublist, but also about whether
dotted lists are permissible arg2's.
- Tried to clarify wording of Proposal to not confuse people about
the relation between NTHCDR and TAILP.
- Added Rationale for choosing ATOM over ENDP.
- Eliminated references to TAILP-NIL:NIL, except as clearly identified
historical reference in the Discussion.
- Updated current practice.
- Added a Non-Benefits section to note JonL's gripe that this might
slow things down slightly.
Hopefully this makes the presentation fair.
-----
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
18-Oct-88, version 3 by van Roggen (just one proposal)
01-Dec-88, version 4 by Pitman (minor edits per discussion)
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two common implementations of this definition are:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eq sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eq list sublist))
(if (eq sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Also at issue is the question of whether dotted lists are permissible
second arguments.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
SUBLIST for some value of N, and false otherwise.
Note, however, that since the LIST may be dotted, so the end test
used by TAILP must be ATOM, not ENDP. That is, if (TAILP x l)
returns T, it means there was n such that (NTHCDR n list) would
return x; however, it doesn't follow that if TAILP returns false,
it is safe to go blithely NTHCDR's into the list looking for it,
since the list might be dotted and NTHCDR might hit bad data.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Some reasons for preferring an ATOM check to ENDP include:
- The name TAILP suggests tails, not sublists. Some users might
expect this distinction to mean that data more general than
proper sublists.
- Making TAILP require lists limits its usefulness. If we did
not make this choice, some users would end up having to write
their own extended TAILP which we could just as well have
provided compatibly.
- TAILP is not considered to be used frequently enough in code
that the minor loss in speed to an ATOM check is worth the
lost functionality. Indeed, expanding the scope of its
capabilities may lead to more uses for TAILP.
- Other operators (eg, APPEND) have recently been extended to
treat dotted lists in an interesting way because users have
expressed a desire for this. As such, this change is
culturally consistent.
- Some implementations already support this feature, and the
wording in CLtL is sufficiently ambiguous that some users
might think it appropriate to depend on the feature. In the
absence of compelling efficiency reasons to the contrary,
we should lean toward extending some implementations rather
than tightening others in our efforts to achieve cross-dialect
consistency.
Test Cases:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns T under this proposal.
#4: (TAILP 3 '(A B C))
returns NIL under this proposal.
#5: (TAILP 3 '(A B C . 3))
returns T under this proposal.
#6: (TAILP '(X Y) '(A B C . 3))
returns NIL under this proposal.
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
Neither Lucid nor VAX LISP currently implements TAILP-NIL:T.
VAX LISP effectively implements definition "A" from the
Problem Description above.
Cost to Implementors:
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Avoids unnecessary incompatibilities between implementations.
Non-Benefits:
Slows down TAILP slightly in some implementations because ENDP is
potentially faster than ATOM.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
It recommended an earlier proposal, TAILP-NIL:NIL, which is effectively
equivalent to Definition "A" from the Problem Description.
Pitman introduced TAILP-NIL:T as an alternative, arguing that the
definition TAILP-NIL:NIL offered no practical value to programmers
in the disputed situations, while TAILP-NIL:T was of arguable usefulness.
Pitman and van Roggen support TAILP-NIL:T.
------- End undelivered message -------
∂01-Dec-88 1112 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1112 CL-Cleanup-mailer Issue: TAILP-NIL (Version 4)
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 11:12:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Thu, 1 Dec 88 11:05:31 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297761; Thu 1-Dec-88 14:11:42 EST
Date: Thu, 1 Dec 88 14:12 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Issue: TAILP-NIL (Version 4)
To: CL-Cleanup@sail.stanford.edu
Message-Id: <881201141215.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Drat. I left out the following in bringing things up to date:
- Gray says TI implements TAILP-NIL:NIL, but that he personally is neutral.
- Sandra supports TAILP-NIL:T.
If another draft ends up getting made, these should get squeezed in.
------- End undelivered message -------
∂01-Dec-88 1205 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; will@cs.uoregon.edu; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1205 CL-Cleanup-mailer Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from mist.math.uoregon.edu ([128.223.4.3]) by SAIL.Stanford.EDU with TCP; 1 Dec 88 12:05:04 PST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Thu, 1 Dec 88 12:01:28 PDT
Received: by fog.cs.uoregon.edu; Thu, 1 Dec 88 12:01:13 PDT
Date: Thu, 1 Dec 88 12:01:13 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8812012001.AA18742@fog.cs.uoregon.edu>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, jonl@lucid.com
Subject: Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Cc: CL-Cleanup@SAIL.Stanford.EDU
Current practice in support of JonL's position: Allegro Common Lisp
for the Macintosh (by Coral), Version 1.0, implements the destructive
form of REVERSE (NREVERSE ?) as REVERSE. I wrote REVERSE! in Common
Lisp and found that it ran a little slower than REVERSE, even taking
gc into account. I suspect that Coral wrote REVERSE in assembly
language, and compiled CL can't compete.
It would be unfair to accuse Coral of being lazy by not implementing
the destructive version destructively. If they were lazy, they'd
have written both of them in Common Lisp instead of assembly language.
------- End undelivered message -------
∂01-Dec-88 1216 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; will@cs.uoregon.edu; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1216 CL-Cleanup-mailer Issue: STREAM-INFO (Version 6)
Received: from rice-chex.ai.mit.edu ([128.52.38.46]) by SAIL.Stanford.EDU with TCP; 1 Dec 88 12:16:31 PST
Received: by rice-chex.ai.mit.edu; Thu, 1 Dec 88 15:15:56 EST
Date: Thu, 1 Dec 88 15:15:56 EST
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8812012015.AA08590@rice-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 30 Nov 88 18:10 PST <881130-181526-3544@Xerox>
Subject: Issue: STREAM-INFO (Version 6)
Return-Path: <masinter.pa@xerox.com>
Date: 30 Nov 88 18:10 PST
From: masinter.pa@xerox.com
Subject: Issue: STREAM-INFO (Version 6)
To: cl-cleanup@sail.stanford.edu
Cc: dick@wheaties.ai.mit.edu (Richard C. Waters)
Reply-To: cl-cleanup@sail.stanford.edu
Cc: Masinter.pa@xerox.com
Issue: STREAM-INFO
We have not yet responded to RWK's comment, viz "Want less generic names.
eg, maybe STREAM-xxx".
What do you think about STREAM-LINE-WIDTH, STREAM-WRITE-SPACE, etc?
Prefixing the names with "STREAM-" is fine with me.
------- End undelivered message -------
∂01-Dec-88 1223 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1223 CL-Compiler-mailer Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 12:22:41 PST
Date: Thu 1 Dec 88 12:01:28-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12451010143.26.IIM@ECLA.USC.EDU>
Re: Issue EVAL-WHEN-NON-TOP-LEVEL
Issue DEFINING-MACROS-NON-TOP-LEVEL
My objections to these proposals are heavily intertwined, so I'm going to
talk about both of them together. First I'll make some specific points about
each of the proposals seperately, then discuss the two of them together.
********************************************************************
Re: Issue EVAL-WHEN-NON-TOP-LEVEL (V1)
Re: paragraph 5 of the Proposal section:
This paragraph specifies that (eval-when (compile) ...) forms nested within
an (eval-when (compile load) ...) form need to be suppressed to avoid multiple
evaluation. For multiple evaluation to occur, the nested form would have to
specify both COMPILE and EVAL, since the invocation of the interpreter by the
outer eval-when will ignore the nested form if it does not specify EVAL (see
paragraphs 2 and 4 of the Proposal section).
I can see arguments on both sides as to whether it is worthwhile to prevent
multiple evaluations due to nested eval-when forms. Con is that there are a
number of other places in the language where multiple evaluation can occur, and
this doesn't seem so very different from those other places. Pro is that these
eval-when forms are being used to cause side-effects, so they really are
different from the other places where multiple evaluation can occur. My
initial reaction to the problem was "why bother", but writing this has
convinced me that there is merit to the proposal to inhibit multiple
evaluations. At this point I'd mildly favor doing so.
Re: Rationale:
If paragraph 5 of the Proposal section is fixed according to my comment
above, then I believe I can agree with the proposal's claim that it is just a
clarification for the top-level case, simply specifying the environment in
which the evaluation occurs.
Re: Cost to Users:
The proposal states that CLtL does not sufficiently specify the behavior of
the following code fragment. Specifically, it says the CLtL is unclear on
whether or not (FOO would ever be called.
(eval-when (compile)
(eval-when (compile)
(foo)))
I don't agree. I claim that a careful reading of CLtL says that (FOO) will not
be called. The relevent sections are:
1. bullet 6, page 70: " ... evaluate each of the forms in the body in the
compiler's executing environment."
2. page 69, second paragraph of eval-when description: "EVAL specifies that
the interpreter should process the body. ... " { None of the other
situations specify that the interpreter should process the body. }
According to (1) EVAL should be called on the inner eval-when form. Since the
inner eval-when form does not specify the EVAL situation, (2) says it gets
ignored (it is the interpreter, not the compiler, which is processing the inner
eval-when form).
While I am perfectly willing to grant that the documentation for eval-when
is obscure and hard to read, I don't think it is particularly ambiguous. It is
my opinion that the problems with the specification of the top-level behavior
of eval-when are editorial issues, not cleanup issues. Its the documentation
that's broken, not the behavior.
Re: Benifits:
It is my opinion that defining forms at non-top-level are already
"meaningful", but not in the way that DEFINING-MACROS-NON-TOP-LEVEL specifies
(which I don't consider "meaningful").
********************************************************************
Re: Issue DEFINING-MACROS-NON-TOP-LEVEL
I can't even agree with the problem description for this issue. Only two
sentences, both of which (in my opinion) are wrong.
CLtL specifically states that the specified defining forms (and by
extension, others that weren't explicitely mentioned) may appear in
non-top-level places. The restriction CLtL makes is that if they are in
non-top-level places, the compiler may not perform its special magic to make
the results of these defining forms available to forms later in the file being
compiled.
If the current proposal for EVAL-WHEN-NON-TOP-LEVEL is accepted, and it is
agreed that implementing defining macros using eval-when forms to cause the
special magic needed to make them visible to further compilation, then I feel
that the resulting semantics for non-top-level defining macros is totally
unreasonable. Under such a proposal, I have serious problems with things like
(when (test) (defmacro foo << definition for foo >>))
Or worse
(if (test)
(defmacro foo << definition 1 for foo >>)
(defmacro foo << definition 2 for foo >>))
Which definition is going to be apparent to further compilation? Whichever one
the implementation's compiler happens to process last? Note that there is
really no compelling a priori reason for processing the clauses of a
conditional in any particular order.
It doesn't bother me to have differing behaviors for defining macros
depending on whether they are at top-level or not. Consider the case of
the functions that the compiler needs to treat specially. They all have
different behaviors, depending on whether or not they are at top-level. I
think anyone would agree that in the following function, the compiler must not
do anything special with the call to EXPORT:
(defun export-from-my-package (symbols)
(export symbols *my-package*))
So I see no problem with putting similar restrictions on defining macros. And
because of the possible existance of control structure around the defining
forms, I don't think the proposed behaviour is even well defined.
If it were agreed that non-top-level defining forms did not become visible
(without recourse to wrapping the whole form in an (eval-when (compile) ...)),
then I would have no problem with having the resulting functions defined in the
proper lexical environment, and would actually prefer that behavior.
********************************************************************
A description of the current IIM Common Lisp implementation of EVAL-WHEN
I'm offering this not as a perfect example of how eval-when should work,
but to show a specific implementation which we believe conforms to CLtL for
top-level behavior, and has what we consider (after looong deliberation and
lots of discussion here) to be reasonable and useful behavior at non-top-level.
Think of it as a strawman for further discussion, and as an indication of where
I'm coming from on this issue.
The following code exhibits the behavior of our current implementation.
The predicates compiler-environment-p and compiler-at-top-level-p have the
obvious meaning. (Note that this really has very little to do with how we
actually implement eval-when, but the behavior should be the same). This
doesn't address the issue of multiple evaluations due to nesting, but that
could easily be fixed.
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
The interesting part of the code, as far as the discussion of these two
issues is concerned, is what is done when COMPILE is specified in a compiler
context. When the eval-when is at top-level, we do the normal thing of calling
EVAL on each of the body forms. However, when not at top-level, we issue a
warning about a top-level form being encountered at non-top-level (ie. in an
unexpected place, where it might not do some of the things you would normally
expect it to (ie. the CLtL caveat is being invoked)).
The reasoning behind this (as I remember it, it being over two years ago
when we made this decision) was that:
1. We wanted to be able to use (eval-when (compile) ...) to implement
defining macros (at least sometimes, we currently don't do all of them
that way). Since it is legitimate for such defining forms to appear at
non-top-level, we needed to specify the behavior of eval-when there too.
2. For reasons described above, we didn't want non-top-level defining macros
to perform their special compile-time magic. That's why we made the body
be ignored in the COMPILE situation when at non-top-level.
3. Because we were preventing the compile-time magic, rather than doing so
silently, we decided to issue a warning about it, so the user would be
informed that something unusual was going on. The warning is non-specific
since the eval-when form doesn't know who created it.
kab
-------
------- End undelivered message -------
∂01-Dec-88 1229 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1229 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 1 Dec 88 12:26:05 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07086; 1 Dec 88 20:00 GMT
Date: Thu, 1 Dec 88 20:03:37 GMT
Message-Id: <20089.8812012003@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Schedules, open issues, etc.
To: sandra <@cs.utah.edu:sandra@defun>, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 30 Nov 88 16:45:05 MST
> Any issue that doesn't have some serious progress made on it within
> the next few weeks will probably be dropped or postponed indefinitely.
I am worried by talk of this sort.
It is OK to drop issues that are effectively language extensions, but
not those that fix real problems in the language. I will be very
disappointed if Common Lisp comes out of X3J13 with known problems
unaddressed just because of some deadline.
Of course, right now we should contine to do as much as possible
as soon as we can. And, where issues are particularly controversial
or complex, we should look for fallback positions that will solve
the problem with minimal chance of introducing new ones. But in
may cases "do nothing" is inadequate.
-- Jeff
------- End undelivered message -------
∂01-Dec-88 1240 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1240 CL-Compiler-mailer Re: CONSTANT-COMPILABLE-TYPES
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 1 Dec 88 12:34:31 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07135; 1 Dec 88 20:06 GMT
Date: Thu, 1 Dec 88 20:09:49 GMT
Message-Id: <20100.8812012009@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: CONSTANT-COMPILABLE-TYPES
To: Cris Perdue <cperdue@sun.com>,
jkf <@NSS.Cs.Ucl.AC.UK,@aiai.edinburgh.ac.uk,@sun.com,@franz:jkf@frisky>
In-Reply-To: Cris Perdue's message of Wed, 30 Nov 88 12:50:30 PST
Cc: cl-compiler@sail.stanford.edu
> It seemed to me that keeping references to the same uninterned
> symbol EQ across an entire file compilation is one more step
> harder than requiring EQ'ness within one quoted constant,
Is it really harder? All the constants could be considered part
of one larger one.
> Also, it wasn't clear to me whether retaining EQ'ness across a
> file would solve a significant set of problems for people.
It would make the semantics simpler and more uniform, and the
semantic complexity is one problem in itself.
It may be that your decision was correct, but I would like to
see if the cost really is high first.
-- Jeff
------- End undelivered message -------
∂01-Dec-88 1251 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; GSB@ALDERAAN.SCRC.Symbolics.COM; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1251 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 12:50:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA06175; Thu, 1 Dec 88 13:49:20 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA13818; Thu, 1 Dec 88 13:49:03 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812012049.AA13818@defun.utah.edu>
Date: Thu, 1 Dec 88 13:49:01 MST
Subject: Re: Schedules, open issues, etc.
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: sandra <sandra%defun@cs.utah.edu>, cl-compiler@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Thu, 1 Dec 88 20:03:37 GMT
> Date: Thu, 1 Dec 88 20:03:37 GMT
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
>
> It is OK to drop issues that are effectively language extensions, but
> not those that fix real problems in the language. I will be very
> disappointed if Common Lisp comes out of X3J13 with known problems
> unaddressed just because of some deadline.
I agree that extensions should have a somewhat lower priority than
fixing known problems. As it happens, most of the issues that appear
to have died are indeed extensions -- for example, issues
SYNTACTIC-ENVIRONMENT-ACCESS and WITH-COMPILATION-UNIT.
Of the issues that are still unresolved, I'd say that the ones dealing
with compiled constants and the three issues that were postponed from
last time have the highest priority, followed by the two that deal with
compilation messages.
-Sandra
-------
------- End undelivered message -------
∂01-Dec-88 1306 Mailer@MCC.COM Message of 30-Nov-88 14:17:39
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 13:06:00 PST
Date: Thu 1 Dec 88 15:02:46-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Message of 30-Nov-88 14:17:39
Message undelivered after 1 day -- will try for another 2 days:
CL-Object-Oriented-Programming@Hal.CAD.MCC.com: Cannot connect to host
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 30 Nov 88 14:17:42-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
-------
∂01-Dec-88 1310 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; GSB@ALDERAAN.SCRC.Symbolics.COM; will@cs.uoregon.edu; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1310 CL-Cleanup-mailer Ballot form
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 13:10:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 DEC 88 12:56:20 PST
Date: 1 Dec 88 12:56 PST
From: masinter.pa@Xerox.COM
Subject: Ballot form
To: cl-cleanup@sail.stanford.edu
Message-ID: <881201-125620-4905@Xerox>
My intention is to allow people to vote "Yes" "No" or
"Yes if.../No but...". If we get a majority of Yes votes, it
passes. If we get a majority of No votes, it fails and we won't
bring it up again. If don't get a majority, we'll look at the
Yes if.../No but... conditions and try to come up with a new
set of proposals that satisfy the constraints.
------- End undelivered message -------
∂01-Dec-88 1311 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; GSB@ALDERAAN.SCRC.Symbolics.COM; will@cs.uoregon.edu; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1311 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 13:10:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 DEC 88 12:56:40 PST
Date: 1 Dec 88 12:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: TEST-NOT-IF-NOT (Version 3)
To: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881201-125640-4906@Xerox>
I added a summary of the negative comments to the discussion
section.
My intention is to allow people to vote "Yes" "No" or
"Yes if.../No but...". If we get a majority of Yes votes, it
passes. If we get a majority of No votes, it fails and we won't
bring it up again. If don't get a majority, we'll look at the
Yes if.../No but... conditions and try to come up with a new
set of proposals that satisfy the constraints.
!
Forum: Cleanup
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Related Issue: FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Performance impact:
Very small; removing the :TEST-NOT keywords would
make the simple implementation of the functions that
used to have them slightly faster, but the resulting
code of the inner loop is likely to be much slower.
Discussion:
Many people objected strongly to both of these proposals --
they might have been a nice idea five years ago, but are
gratuitous incompatibilities now: incompatible changes with
insufficient payback.
Some of those objections might be tempered if some additional
changes were made to Common Lisp: adding a COMPLEMENT
function, or if there were a strategy to declare some parts of the
language "obsolete". Since these conditions haven't been done,
their objections stand.
Steele noted that one main reservation to FLUSH-ALL is that
he uses REMOVE-IF-NOT much more than REMOVE-IF.
This issue is related to FUNCTION-COMPOSITION, but is not dependent
on it. Some support the combination of FLUSH-ALL and
the NEW-FUNCTIONS part of FUNCTION-COMPOSITION
in spite of the incompatible change because of the aesthetic appeal.
Some people expressed their intention to vote for FLUSH-ALL
only if FUNCTION-COMPOSITION:NEW-FUNCTIONS.
It was noted that and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
The modification of these functions is moot for those who
prefer to use extended LOOP macro/iteration constructs
in lieu of the sequence functions.
Several alternative names for REMOVE-IF-NOT were
suggested: KEEP-IF, ABSTRACT, FILTER. We did not
pursue these suggestions.
------- End undelivered message -------
∂01-Dec-88 1355 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; GSB@ALDERAAN.SCRC.Symbolics.COM; will@cs.uoregon.edu; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1355 CL-Cleanup-mailer Issue ALIST-NIL
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 13:50:00 PST
Date: Thu 1 Dec 88 13:48:59-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue ALIST-NIL
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12451029718.28.IIM@ECLA.USC.EDU>
As an actual "real-world" example of the second usage described under "Cost
to Users", my boss mentioned that he worked out an implementation of Baker's
Shallow Binding scheme (1) that depended on permitting Nil to be an ignored
alist entry. He admits that it could have been written using an alternative
mechanism like that described in the proposal. However, doing so might ugly,
since it might be necessary to go to extra trouble to reuse that special cell
rather than gratuitously consing up a new one all the time.
kab
(1) "Shallow Binding in Lisp 1.5", Henry G. Baker, Jr., Communications of the
ACM, July 1978, Volume 21, Number 7, page 565.
-------
------- End undelivered message -------
∂01-Dec-88 1403 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
clclean@clam.sun.com; GSB@ALDERAAN.SCRC.Symbolics.COM; will@cs.uoregon.edu; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1403 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Dec 88 14:02:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 501137; Thu 1-Dec-88 17:02:43 EST
Date: Thu, 1 Dec 88 17:02 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 3)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881201-125640-4906@Xerox>
Message-ID: <881201170231.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I would like the ballot query on this to make it clear that among
the things people might vote is
``Yes, if you change "REMOVE" to "DEPRECATE" and define the
term "DEPRECATE" in a way that permits the retention of these
primitives for the near term with intent to phase them out
later.''
You may want to create a small separate blurb on what deprecation is
about to accompany the issue writeups, and then have the voting
instructions for particular issues refer people to the fact that
such a change might make the issue palatable to them.
Alternatively, we could include full writeups on additional options
such as DEPRECATE-ALL,etc. so that people didn't have to think up
the idea on their own. Although procedurally that sounds like more
work, if there is any chance that this issue will fail for lack
of having done so, I think it would be worth the work.
------- End undelivered message -------
∂01-Dec-88 1428 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1428 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 14:28:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA10074; Thu, 1 Dec 88 15:27:09 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA13876; Thu, 1 Dec 88 15:26:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812012226.AA13876@defun.utah.edu>
Date: Thu, 1 Dec 88 15:26:50 MST
Subject: Re: Schedules, open issues, etc.
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 1 Dec 88 16:17 EST
> Date: Thu, 1 Dec 88 16:17 EST
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
>
> Your notion of what appears to have died is very interesting.
My notion of things that appear to have died are issues where a
proposal was submitted, discussion took place, and there was a promise
of a revised proposal; but where I haven't seen either the revised
proposal or even an answer to my queries about whether or not you were
still planning to produce one. As I've said many times before, I'm
not a mind reader, and if people don't speak up (or tell me that
they're going to speak up when they have more time), I've got to
assume it's because they don't have anything to say.
Time-wise, I'm in the same boat as everybody else. (Contrary to what
you seem to think, I'm not "employed full-time" to work on this. In
fact, I'm not employed to work on it at all -- it's something I do in
my spare time and largely at my own expense.) I realize that it's hard
to stick to hard-and-fast schedules because of this, but if we
procrastinate indefinitely the standard will never get finished.
Anyway, thanks for telling me that you haven't written off
WITH-COMPILATION-ENVIRONMENT. I certainly didn't want to discourage
you from pursuing this issue, it's just that I don't think I'd have
time to do anything on it myself in time for the January meeting.
-Sandra
-------
------- End undelivered message -------
∂01-Dec-88 1520 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1520 CL-Compiler-mailer Re: Schedules, open issues, etc.
Received: from argus.stanford.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 15:20:14 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.stanford.edu with TCP; Thu, 1 Dec 88 15:12:52 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297835; Thu 1-Dec-88 16:16:29 EST
Date: Thu, 1 Dec 88 16:17 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Re: Schedules, open issues, etc.
To: sandra%defun@cs.utah.edu
Cc: jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk, cl-compiler@sail.stanford.edu
In-Reply-To: <8812012049.AA13818@defun.utah.edu>
Message-Id: <881201161709.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Your notion of what appears to have died is very interesting.
Perhaps you are full-time employed to do this work, or perhaps you
have a regular amount of time you are able to devote, but my time
and that of others in these discussions must often run in bursts,
constantly switching back and forth between topics (some CL-related,
some "work"-related).
Just because I haven't sent mail in some unit time does not mean
I have dropped it, it just means I have been diverted by matters of
higher priority. I have been talked into dropping some proposals
(or parts thereof) for lack of resources, but always such has been
done explicitly. I do not considers that topics die simply for lack
of being touched in some arbitrary and unagreed-upon threshold period
of time.
In particular, I don't consider WITH-COMPILATION-UNIT to be dead,
nor do I consider it to be "an extension". It involves an extension,
but its stated intent is to fix what I consider to be a remarkably
serious user interface problem with COMPILE-FILE.
------- End undelivered message -------
∂01-Dec-88 1520 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1520 CL-Cleanup-mailer Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from argus.stanford.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 15:20:03 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.stanford.edu with TCP; Thu, 1 Dec 88 15:12:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297803; Thu 1-Dec-88 15:29:55 EST
Date: Thu, 1 Dec 88 15:30 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: will@fog.cs.uoregon.edu
Cc: KMP@stony-brook.scrc.symbolics.com, jonl@lucid.com,
CL-Cleanup@sail.stanford.edu
In-Reply-To: <8812012001.AA18742@fog.cs.uoregon.edu>
Message-Id: <881201153036.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 1 Dec 88 12:01:13 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Current practice in support of JonL's position: Allegro Common Lisp
for the Macintosh (by Coral), Version 1.0, implements the destructive
form of REVERSE (NREVERSE ?) as REVERSE. I wrote REVERSE! in Common
Lisp and found that it ran a little slower than REVERSE, even taking
gc into account. I suspect that Coral wrote REVERSE in assembly
language, and compiled CL can't compete.
It would be unfair to accuse Coral of being lazy by not implementing
the destructive version destructively. If they were lazy, they'd
have written both of them in Common Lisp instead of assembly language.
On the other hand, that's not to say that if they'd assembly coded
NREVERSE (REVERSE!) they wouldn't have been faster, so your experiment
is not really as well-controlled as it might be.
In any case, we're not in the business of enforcement, we're only in the
business of legislation. They (Coral) are entitled to do what they think
is best and justify it as they will, and then the market place will stand
jury -- as they do with us all. My point is only that we should do our
best to present the issues as best we can so that users will know where to
expect what and why. An awful lot of court trials these days are not
about absolute rights and wrongs, but violations of "reasonable expectation".
We should do our best to aid users (and implementors) in forming reasonable
expectations where we have the foresight to do so.
------- End undelivered message -------
∂01-Dec-88 1520 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1520 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from argus.stanford.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 15:20:01 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.stanford.edu with TCP; Thu, 1 Dec 88 15:12:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297792; Thu 1-Dec-88 15:20:35 EST
Date: Thu, 1 Dec 88 15:21 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: CL-Cleanup@sail.stanford.edu
Message-Id: <881201152112.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok, here's what I did in the proposal below:
* Changes to proposal
- Elaborate on each issue. Say more than just "is valid".
Hopefully this will make any need for line-item veto easier.
- I changed the treatment of INPUT-STREAM-P and OUTPUT-STREAM-P
because I couldn't live with claiming that a closed stream was
no longer of the same type. (This is like saying that a dead
man is neither man nor woman. I've never bought into this
nonsense. You never know when you'll find out they were only
faking and there's no sense in revising your entire belief
system just to accomodate a bit which is really orthogonal.)
If Masinter thinks it's useful to be able to detect that these
streams can't have I/O done to them, I'm ammenable to adding
an OPEN-STREAM-P primitive.
- I clarified the treatment of PATHNAME and friends in a way
that might not have been compatible.
In general, read the Proposal carefully with a fresh eye.
* Very minor cosmetic reformatting to most of sections. With the
exception of Aesthetics, where I turned "Yes" into a full sentence,
I didn't change the actual wording of any of other sections.
-----
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (CLtL p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
13-Oct-88, Version 3 by van Roggen
1-Dec-88, Version 4 by Pitman
Related Issues: STREAM-ACCESS, STREAM-INFO
Status: For Internal Discussion
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
``The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ...''
but the list of inquiry operations is not specified.
At least one implementation interpreted the list to include at least
OUTPUT-STREAM-P, while another has disallowed that operation to be
performed on a closed stream.
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
Clarify the behavior of the following functions on closed streams:
* STREAMP is unaffected by whether its stream argument is open or closed.
* INPUT-STREAM-P and OUTPUT-STREAM-P are unaffected by whether their
stream arguments are open or closed.
This is not the same as saying that once a stream is determined to be
an input-stream, it will always be. For example, if an implementation
provides an implementation-specific way to change the direction of a
stream, that implementation-dependent code may affect the output of
these functions. Similarly, in implementations where it is possible to
re-open a closed stream in some ways, the effect of so doing is not
prohibited from opening the stream with different direction, etc.
However, as long as only Common Lisp functions are used, INPUT-STREAM-P
and OUTPUT-STREAM-P of a stream will remain constant over time.
* If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed without error but the return value is not specified.
* PATHNAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it would in principle be possible for PATHNAME in
some implementations to return more specific information after the
stream is closed. For consistency, however, PATHNAME is prohibited
from doing this. PATHNAME (which is valid only on file streams, of
course) must return the same pathname after a file is closed as it
did before.
* TRUENAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it is permissible TRUENAME to return more specific
information after the stream is closed.
* MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING,
ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
For any of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
* PROBE-FILE and DIRECTORY are valid on either open or closed streams.
For either of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
In this case of these operators however, closed stream may well be the
most reliable arguments in some cases, since treatment of open streams
to the file system may vary considerably between implementations.
For example, in some operating systems, open files are written under
temporary names and not renamed until close and/or are held invisible
until a close is performed. In general, any code with an intent to be
highly portable should tread lightly when using PROBE-FILE or
DIRECTORY.
* If proposal STREAM-ACCESS:PROVIDE is adopted, all of its functions
will work on closed streams. That is, the effect of calling any of
the operations introduced by that proposal on a stream is the same
whether the stream is open or closed.
* If proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is adopted, none
of its functions are required to work on closed streams. That is,
the effect of calling any of the operations introduced by that
proposal on a closed stream is undefined.
Rationale:
One can consider many characteristics of a stream to be independent of
the ability to do I/O. Being able to determine a stream's direction and
its name is often useful for debugging. A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams. Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Cost to Implementors:
Unknown, but likely to be small in most implementations.
A nontrivial amount of work may be necessary if the pathname information
is held externally and is normally deleted when the stream is closed.
The implementation will have to copy the information at some time for later
inquiries.
Cost to Users:
None.
Benefits:
These clarifications will assist users in writing portable code.
Aesthetics:
Most people will probably see these clarifications as an improvement
in aesthetics.
Discussion:
There are some separate, but related, issues regarding what CLOSE
should do on composite streams or constructed streams.
------- End undelivered message -------
∂01-Dec-88 1534 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
28-Nov-88 1745 Common-Lisp-mailer inconsistency in backquote spec?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST
Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: common-lisp@sail.stanford.edu
Message-ID: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
If you look at most implementations, and at the examples on pg 351, then
you'd think it should be `(a . b)
However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
I tried Ibuki, Franz, Lucid, and Genera.
In all of them evaluating '`(,@'(a . b)) => `(a . b).
In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil)
while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b)
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
------- End undelivered message -------
∂01-Dec-88 1634 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1634 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 16:34:43 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA07752@EDDIE.MIT.EDU>; Thu, 1 Dec 88 19:32:48 EST
Received: by spt.entity.com (smail2.5); 1 Dec 88 19:17:10 EST (Thu)
To: will@fog.cs.uoregon.edu
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, jonl@lucid.com,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: William Clinger's message of Thu, 1 Dec 88 12:01:13 PDT <8812012001.AA18742@fog.cs.uoregon.edu>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Message-Id: <8812011917.AA19208@spt.entity.com>
Date: 1 Dec 88 19:17:10 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
Yikes! The REVERSE/NREVERSE thing in Coral v1.0 was a bug! It's been fixed
in subsequent releases. The only "destructive" operations we intentionally
don't do destructively are those that would require changing the size of a
simple array.
------- End undelivered message -------
∂01-Dec-88 1634 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1634 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 16:34:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 DEC 88 16:27:03 PST
Date: 1 Dec 88 16:26 PST
From: masinter.pa@Xerox.COM
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <881201-162703-5359@Xerox>
I never wrote this up, even though it seems to be required in some of the
COERCE discussions.
Should TYPE-OF be required to be more specific on condition subtypes?
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it useless for
portable applications, outside of structures. In particular, there are no
constraints on the value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF must be at least as specific as follows:
For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME
CONDITION, RESTART.
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a recognized subtype of it.
The result of TYPE-OF must satisfy
(TYPEP object (TYPE-OF object)).
The result of TYPE-OF must be an acceptable input to SUBTYPEP.
The result of TYPE-OF cannot contain be a MEMBER type specifier, or T.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
Inability to use TYPE-OF in portable code except for information display.
Performance impact:
Likely none.
Benefits:
Removal of "cost of non-adoption".
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
------- End undelivered message -------
∂01-Dec-88 1709 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1709 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 17:09:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 DEC 88 16:58:43 PST
Date: 1 Dec 88 16:58 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
In-reply-to: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>'s message
of Thu, 1 Dec 88 15:21 EST
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <881201-165843-5438@Xerox>
In the implementations I've been most familiar with, INPUT-STREAM-P and
OUTPUT-STREAM-P are predicates on state rather than on "class".
That is, a "stream" can have one of several states: closed, open for input,
open for output, open for both input/output.
CLOSE transitions a stream from one of the "open" states to one to the
closed state.
Well, anyway, that's how I think of it. In Interlisp, OPENP was the
predicate, you could ask just (OPENP x) or (OPENP x 'INPUT) or (OPENP X
'OUTPUT) or (OPENP X 'BOTH).
------- End undelivered message -------
∂01-Dec-88 1742 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 1742 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Dec 88 17:42:05 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 501451; Thu 1-Dec-88 20:41:44 EST
Date: Thu, 1 Dec 88 20:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881201-165843-5438@Xerox>
Message-ID: <881201204134.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
I'm probably at least as uncomfortable with your way of thinking about it as
you are with mine. However, I think they're both fairly arbitrary positions
which can only be successfully argued for in terms of some set of pragmatic
details which may vary between your environment and mine.
I recommend, therefore, that we introduce OPEN-STREAM-P to detect whether a
stream is open, because I think we can agree on that much. I think we should
say that OPEN makes a stream which is open, that CLOSE closes a stream if
it's meaningful to do that -- we can probably define that for particular kinds
of streams, like file streams, that it really must do a close while leaving
anything we're unsure of undefined. OPEN-STREAM-P would not be a way to tell
whether CLOSE had been called, but rather whether open-stream operations were
permissible.
Having OPEN-STREAM-P, I think the appropriate compromise to satisfy both your
culture and mine is to say that calling INPUT-STREAM-P and OUTPUT-STREAM-P
on a closed stream will return an undefined value (actually, we can even say
that the value will be one of T or NIL -- but we cannot be more specific about
when it will be what, since we leave this up to an implementation). We should
make clear that the rationale is that there are different models of what
closed stream direction is, which we have no reason to violate because in
practice there is no useful Common Lisp program which we anticipate being able
to write based on such a distinction given the existing primitives, and so
there's no reason to force implementations to gratuitously agree.
If this is acceptable, and you want me to draft it up, let me know.
------- End undelivered message -------
∂01-Dec-88 2042 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 2042 CL-Compiler-mailer Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Dec 88 20:42:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA18333; Thu, 1 Dec 88 21:41:36 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA14009; Thu, 1 Dec 88 21:41:28 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812020441.AA14009@defun.utah.edu>
Date: Thu, 1 Dec 88 21:41:27 MST
Subject: Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
Cc: cl-compiler@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett <IIM@ECLA.USC.EDU>, Thu 1 Dec 88 12:01:28-PST
Thanks for taking the time to set out your arguments in writing. Rather
than address all of your specific comments at this time, I'd like to
concentrate on one remark:
> CLtL specifically states that the specified defining forms (and by
> extension, others that weren't explicitely mentioned) may appear in
> non-top-level places. The restriction CLtL makes is that if they are in
> non-top-level places, the compiler may not perform its special magic to make
> the results of these defining forms available to forms later in the file being
> compiled.
That may be your interpretation of what CLtL says, but it doesn't
really say that explicitly. I don't have my copy handy right now, but
if my memory of chapter and verse serves me correctly, it says
something like "the compiler may not *recognize* these forms in other
than top-level locations". And indeed, there are (or at least were) a
couple of implementations in which the compiler simply did not compile
them correctly except at top-level.
All this isn't to say that your interpretation would not be a
reasonable behavior. As I understand it, the key to what you are
proposing is making (EVAL-WHEN (COMPILE) ...) cause compile-time
evaluation only if it appears at top-level.
I'd be happy to prepare revised proposals along these lines if I get some
feedback that this direction would be acceptable to others on the
committee. So, what do the rest of you think?
-Sandra
-------
------- End undelivered message -------
∂01-Dec-88 2217 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 0014 Common-Lisp-mailer inconsistency in backquote spec?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST
Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811290810.AA00624@bhopal>
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
------- End undelivered message -------
∂01-Dec-88 2218 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:18:13 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA19459; Thu, 1 Dec 88 22:17:11 PST
Date: Thu, 1 Dec 88 22:17:11 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8812020617.AA19459@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA19457; Thu, 1 Dec 88 22:17:11 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA08142; Thu, 1 Dec 88 22:17:14 PST
Message-Id: <8812020617.AA08142@ucbarpa.Berkeley.EDU>
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:04:56 PST
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
...but I believe it is the case that there is no CL way to determine
if a given type is defined.
I wish there was some CL way to define a complex type and insert it in
the existing hierarchy. For example, I once tried to define the type
LIST-OF, which would be used like
(TYPEP '(1 2 3) '(LIST-OF FIXNUM)) ==> T
(TYPEP '(A B 3) '(LIST-OF FIXNUM)) ==> NIL
(SUBTYPEP '(LIST-OF SYMBOL) 'LIST) ==> T
(SUBTYPEP '(LIST-OF FIXNUM) '(LIST-OF NUMBER)) ==> T
(SUBTYPEP '(LIST-OF *) '(LIST-OF LIST)) ==> NIL NIL
On the TI Explorer this was really easy.
In Lucid CL, it was not possible except by bashing the definitions of
TYPEP and SUBTYPEP.
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Jamie
∂01-Dec-88 2229 Mailer@MCC.COM Message of 2-Dec-88 00:28:08
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:29:09 PST
Date: Fri 2 Dec 88 00:28:16-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 2-Dec-88 00:28:08
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Dec 88 00:28:09-CST
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:04:56 PST
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
...but I believe it is the case that there is no CL way to determine
if a given type is defined.
I wish there was some CL way to define a complex type and insert it in
the existing hierarchy. For example, I once tried to define the type
LIST-OF, which would be used like
(TYPEP '(1 2 3) '(LIST-OF FIXNUM)) ==> T
(TYPEP '(A B 3) '(LIST-OF FIXNUM)) ==> NIL
(SUBTYPEP '(LIST-OF SYMBOL) 'LIST) ==> T
(SUBTYPEP '(LIST-OF FIXNUM) '(LIST-OF NUMBER)) ==> T
(SUBTYPEP '(LIST-OF *) '(LIST-OF LIST)) ==> NIL NIL
On the TI Explorer this was really easy.
In Lucid CL, it was not possible except by bashing the definitions of
TYPEP and SUBTYPEP.
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Jamie
-------
∂01-Dec-88 2205 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
yang%softy.DEC@decwrl.ARPA; common-lisp@gmdzi.uucp@UUNET.UU.NET; coffee@AEROSPACE.AERO.ORG
Here is how the remote host replied to this mail address:
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
01-Dec-88 2205 Common-Lisp-mailer Re: commonlisp types
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:04:56 PST
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
...but I believe it is the case that there is no CL way to determine
if a given type is defined.
I wish there was some CL way to define a complex type and insert it in
the existing hierarchy. For example, I once tried to define the type
LIST-OF, which would be used like
(TYPEP '(1 2 3) '(LIST-OF FIXNUM)) ==> T
(TYPEP '(A B 3) '(LIST-OF FIXNUM)) ==> NIL
(SUBTYPEP '(LIST-OF SYMBOL) 'LIST) ==> T
(SUBTYPEP '(LIST-OF FIXNUM) '(LIST-OF NUMBER)) ==> T
(SUBTYPEP '(LIST-OF *) '(LIST-OF LIST)) ==> NIL NIL
On the TI Explorer this was really easy.
In Lucid CL, it was not possible except by bashing the definitions of
TYPEP and SUBTYPEP.
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Jamie
------- End undelivered message -------
∂01-Dec-88 2348 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
01-Dec-88 2348 CL-Cleanup-mailer Re: Issue: TAILP-NIL (Version 4)
Received: from RELAY.CS.NET (GW1.CS.NET) by SAIL.Stanford.EDU with TCP; 1 Dec 88 23:47:55 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa26115; 2 Dec 88 1:01 EST
Received: from draper.com by RELAY.CS.NET id aa09871; 2 Dec 88 0:50 EST
Date: Fri, 2 Dec 88 00:01 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: TAILP-NIL (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
re: test case #5:
(TAILP 3 '(A B C . 3))
returns T under this proposal.
Not necessarily. It must be kept in mind that numbers are not necessarily EQ.
I know you believe that all implementations have immediate fixnums, but this
isn't the case with ours (tho it hurts to admit it).
------- End undelivered message -------
∂02-Dec-88 0153 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 0153 CL-Cleanup-mailer Re: Issue: TAILP-NIL (Version 4)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 2 Dec 88 01:53:26 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 408896; Fri 2-Dec-88 04:19:05 EST
Date: Fri, 2 Dec 88 04:16 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAILP-NIL (Version 4)
To: SEB1525@draper.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 2 Dec 88 00:01 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
Message-ID: <881202041609.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 2 Dec 88 00:01 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
re: test case #5:
(TAILP 3 '(A B C . 3))
returns T under this proposal.
Not necessarily. It must be kept in mind that numbers are not necessarily EQ.
I know you believe that all implementations have immediate fixnums, but this
isn't the case with ours (tho it hurts to admit it).
Good point. Clearly the bug is that we say EQ and not EQL in the
description. Hardly anything defaults to EQ tests, after all. This
would be irregular if we let it through using EQL.
Someone's going to tell me that this slows it down again. [It needn't
slow it much, of course, though for inlined code you'd get a little code
bloating because you'd have to jumpt to one of two loops. For TAILP
notinline, it would be little overhead to have the two loops. I don't
know how many implementations inline this, though -- certainly ours
doesn't]
Does anyone think that making it use EQL rather than EQ is going to be
prohibitive?
------- End undelivered message -------
∂02-Dec-88 0223 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 0223 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Dec 88 02:23:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 501647; Fri 2-Dec-88 05:23:29 EST
Date: Fri, 2 Dec 88 05:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881202052314.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Since there was some criticism of the problem statement, I fixed that.
Since there was no agreement on which way to go, I decided to take the
conservative approach and just justify the status quo. This proposal
is very different than any of the previous versions.
-----
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
Some of the original Common Lisp designers assert that the
:ADJUSTABLE option exists in order to allow a user to select
between getting adjustable and non-adjustable arrays.
Others of the original Common Lisp designers assert that the
:ADJUSTABLE option existed to permit implementations in which
making all arrays adjustable was very expensive to make some
arrays not adjustable.
The former camp therefore believes that :ADJUSTABLE NIL means
that the array MUST be non-adjustable. The latter camp believes
that :ADJUSTABLE NIL means that the array MIGHT be non-adjustable.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' Although this sentence
is slightly ambiguous (one might argue that :ADJUSTABLE NIL
involves supplying the :ADJUSTABLE option), it is generally
interpreted to mean that ``... with :ADJUSTABLE T.''
One problem is that since ADJUSTABLE-ARRAY-P does not predicate
whether the :ADJUSTABLE option was provided, then
ADJUSTABLE-ARRAY-P is not an appropriate predicate in all
implementations to determine whether an array is adjustable.
Technically, :ADJUSTABLE NIL could create and adjustable array
(one for which ADJUSTABLE-ARRAY-P returns true), and yet
ADJUST-ARRAY might refuse to adjust it (if it had recorded a
separate bit saying whether :ADJUSTABLE T had been specified
and used that bit for ADJUST-ARRAY). Fortunately, this problem
has not been observed to occur in practice, but it is present
in principle.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY. That expectation is violated by
legitimate implementations, since it is permissible for an
implementation to create an adjustable array even though it has
not been asked for, and since calling adjust array on such an
array "is an error" (and hence the behavior can be extended).
This perceived lack of error checking may become a legitimate
portability error to someone who has debugged his code in a
an implementation where :ADJUSTABLE NIL arrays might still be
adjustable and then tried ported his code to an implementation
which is more conservative in its interpretation.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:STATUS-QUO):
Document clearly that omitting the :ADJUSTABLE option to MAKE-ARRAY
or explicitly supplying :ADJUSTABLE NIL may not guarantee a non-adjustable
array. ADJUSTABLE-ARRAY-P MUST be true of an array created using
:ADJUSTABLE T, and MIGHT be true of an array created with no :ADJUSTABLE
option or with :ADJUSTABLE NIL.
Change the description of ADJUST-ARRAY to say that the effect of
adjusting an array which "is not adjustable" (vs "was not created with
the :ADJUSTABLE option") is not defined.
Clarify that this legitimizes ADJUSTABLE-ARRAY-P an appropriate predicate
to determine whether ADJUST-ARRAY will reliably succeed.
Define that if ADJUSTABLE-ARRAY-P of the array given to ADJUST-ARRAY is
false, then an error must be signalled.
Rationale:
This effectively makes the status quo explicit.
While changing this to a tighter interpretation would be desirable, some
implementations have suggested that such a change might be very expensive
or impossible given their existing data storage layouts.
Although technically the changes to ADJUST-ARRAY are incompatible changes
from the spec, it's not believed that there are any implementations which
deviate, so we're still categorizing this as a clarification.
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and is compatible with this proposal.
Symbolics Cloe makes :ADJUSTABLE NIL arrays non-adjustable in all cases,
and is compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
------- End undelivered message -------
∂02-Dec-88 0235 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 0235 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Dec 88 02:35:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 501651; Fri 2-Dec-88 05:35:13 EST
Date: Fri, 2 Dec 88 05:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: gsb@ALDERAAN.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881202043914.5.GSB@GANG-GANG.SCRC.Symbolics.COM>
Message-ID: <881202053502.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Added CL-Cleanup back.]
Date: Thu, 1 Dec 88 23:39 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <881201204134.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
... Keep in mind whatever things go on with the "aggregate" streams,
e.g. bidirectional in particular might have semantic problems with
open-stream-p. ...
Actually, in Masinter's approach, you have the inverse problem with
INPUT-STREAM-P. What does it return on an aggregrate output stream
when some of the streams are closed and some are not.
On the basis of this, I retract my previous suggestion that we get
involved in OPEN-STREAM-P, and instead suggest that we just say
it's an error to call INPUT-STREAM-P or OUTPUT-STREAM-P (or WRITE or ...)
on any stream which has been closed or on any aggregrate stream
for which a component stream has been closed. People won't be able to
predicate this at runtime -- they'll just have to watch their control
flow and not let one of these things get into the hands of CLOSE.
I guess that correctly sums up the status quo, so it can't be any
worse than what we've got now. And what we have now isn't that bad --
every now and then someone complains that they wish they could tell if
a stream is open, but I've generally been able to look at their code and
show them how to rewrite it so that the issue didn't come up.
------- End undelivered message -------
∂02-Dec-88 0325 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 0325 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Dec 88 03:25:15 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 501670; Fri 2-Dec-88 06:25:03 EST
Date: Fri, 2 Dec 88 06:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881201-162703-5359@Xerox>
Message-ID: <881202062445.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Can you clarify what a "recognized subtype" is? Is it something that
CLtL readers would recognize (ie, a term introduced in CLtL) or is
something that SUBTYPEP would recognize (ie, spanning implementation-specific
types).
Is it really true that CLOS already presumes that TYPE-OF is in good order?
I looked quickly at the spec and it seems to define CLASS-OF in terms of
TYPE-OF. If that quick impression is correct, then you should really mention
this fact either in the problem description or the rationale to offer it the
prominence its due since if this issue is not resolved, the portability of
all methods on built-in classes will have questionable value.
On the other hand, if CLOS also offers information about how CLASS-OF
can get its info without going through TYPE-OF, then some verbiage belongs
in the Proposal part saying that in all cases where CLASS-OF is well-defined
and would return a class which has a proper name, then TYPE-OF should return
that proper name -- no?
I'm a bit tired at this point, so if I'm not completely coherent on these
issues, I apologize. But since I'm going away on vacation soon, I wanted to
get my thoughts onto the books.
My impression is that the wording of this proposal might need a little
tightening here and there but that the general idea is right.
------- End undelivered message -------
∂02-Dec-88 0742 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1009 Common-Lisp-mailer Common Lisp for SUNS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:09:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01681g; Tue, 29 Nov 88 10:06:59 PST
Received: by bhopal id AA01309g; Tue, 29 Nov 88 10:05:50 PST
Date: Tue, 29 Nov 88 10:05:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8811291805.AA01309@bhopal>
To: bill@red.ipsa.dnd.ca
In-Reply-To: Bill Pase's message of Tue, 29 Nov 88 11:14:29 EST <8811291614.AA01479@red.ipsa.dnd.ca>
Subject: Common Lisp for SUNS
Cc: common-lisp@sail.stanford.edu
I'm not the right person to send you benchmark data on Lucid Common
Lisp, but I thought I should mention that Sun Common Lisp is Lucid
Common Lisp. (Lucid makes it, Sun sells it.)
Also, I can give some general advice about benchmarks:
(1) Be sure to note the releases being compared. For example, LCL
Version 3.0 is significantly different from LCL Version 2.1. We
added a second compiler, an ephemeral garbage collector,
multi-tasking, better inline floating point code, new interrupts,
new I/O, etc., etc.
(2) Be sure that the person who produced the benchmark values
understands the benchmarks and the lisp being tested. Proper use
of declarations and compiler settings can sometimes produce
order-of-magnitude differences. Also, for example, the use of a
feature such as ephemeral garbage collection may reflect a
decision to accept a somewhat increased running time in order to
avoid detectable pauses for GC. Turning EGC off may result in
different (usually faster) benchmark values, and might or might
not be appropriate for various applications. You need to
understand how you're going to use the lisp to know what settings
are appropriate.
(3) Ask for the *precise* techniques used to obtain the benchmarks,
including processor speed, memory size, load on the machine, etc.
I know that some of the people at Lucid have produced benchmark
figures using what we call the "low-mode" -- we run each
benchmark about 20 times or more, then use some statistics to
produce a number one could expect to be the low value obtained
in a typical set of about 3 runs. (We didn't want to just
scrounge for the lowest value, since that's not always
reproducible, yet did want to give a fair indication of the
performance possible.) I'm pretty sure the techniques used are
distributed with the benchmark numbers.
(4) If performance is critical, explain this to the vendor. For
example, Lucid is now productizing tools to reorganize your code
based on an analysis of its dynamic performance, since code and
data locality can have order-of-magnitude affects on real-life
applications. Remember that you are going to be running
applications day-to-day, and not just benchmarks. Support in
this area can be as crucial as the underlying speed of the lisp!
Happy hunting,
jlm
------- End undelivered message -------
∂02-Dec-88 0743 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 0813 Common-Lisp-mailer Common Lisp for SUNS
Received: from red.ipsa.dnd.ca by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:13:45 PST
Received: by red.ipsa.dnd.ca; (5.54/4.7)
id AA01479; Tue, 29 Nov 88 11:14:29 EST
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Message-Id: <8811291614.AA01479@red.ipsa.dnd.ca>
To: common-lisp@sail.stanford.edu
Subject: Common Lisp for SUNS
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
------- End undelivered message -------
∂02-Dec-88 0743 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 0906 Common-Lisp-mailer Common Lisp for SUNS
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:04:27 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 29 Nov 88 12:02:03 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 29 Nov 88 12:02:57 EST
Date: Tue, 29 Nov 88 12:03 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881129170307.7.BARMAR@OCCAM.THINK.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
Can anyone tell me about their experiences with Common Lisp systems
for Sun Computers. I know of four implementations, Kyoto Common Lisp,
Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp.
Sun Common Lisp currently is Lucid Common Lisp. There were rumors last
year that they would be switching to Franz (who makes Allegro CL), but
this doesn't appear to have happened.
Kyoto CL is not generally considered a high-performance Lisp. Its major
feature is its portability, since it is written mostly in C and its
compiler uses C as the intermediate language. It is also well-known for
being very faithful to CLtL, implementing all and only what the book
says.
barmar
------- End undelivered message -------
∂02-Dec-88 0743 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 0937 Common-Lisp-mailer inconsistency in backquote spec?
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:59 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 12:34:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 12:35:41 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 12:34:10 EST
Received: by joplin.think.com; Tue, 29 Nov 88 12:35:36 EST
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Message-Id: <8811291735.AA00711@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
------- End undelivered message -------
∂02-Dec-88 0709 Mailer failed mail returned
To: CL-Windows-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
puccio@MEDIA-LAB.MEDIA.MIT.EDU; weissman@apollo.com; hultquis@prandtl.nas.nasa.gov; lispx-gmd@gmdzi.uucp@UUNET.UU.NET; eric@SCUBED.ARPA; MARSHALL%PLU@IO.ARC.NASA.GOV; TAYLOR%PLU@IO.ARC.NASA.GOV; marone@AIC.NRL.NAVY.MIL; York@Chuck-Jones.ILA-West.Dialnet.Symbolics.COM
Here is how the remote host(s) replied to these mail addresses:
puccio@MEDIA-LAB.MEDIA.MIT.EDU
550 <puccio@MEDIA-LAB.MEDIA.MIT.EDU>... User unknown
lispx-gmd@gmdzi.uucp@UUNET.UU.NET
550 <"lispx-gmd@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
tk%moss@ATT.ARPA
421 research.att.com too busy, please try later
blewett%research.att.com%siriusb@RESEARCH.ATT.COM
421 research.att.com too busy, please try later
------- Begin undelivered message: -------
02-Dec-88 0709 CL-Windows-mailer streams to common lisp windows.
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:08:56 PST
Date: 1 Dec 88 11:06:47 EST
From: Timothy Daly <DALY@ibm.com>
To: cl-windows@sail.stanford.edu
Message-Id: <120188.110651.daly@ibm.com>
Subject: streams to common lisp windows.
Well, I HAVE succeeded in implementing a function that will return
the READ of a window. It is truly ugly but it works. The essential
steps are:
catch :exit
event-case to capture keycodes (NOT ascii)
when :key-press
convert key to ascii
when key is of type character
concat to buffer
if key is a constituent char
then exit event-case
else continue event-case
event-case to throw away the key event (discard-p t)
condition-case (with-input-from-string (s buffer) (setq result (read s)))
on simple-condition-error (setq result :fail)
unless (eq result :fail) (throw :exit result)
essentially, i capture each key-press event, convert it to ascii,
and if it is an ascii character I add it to the buffer. The constituent
character check is there to wait until there is some terminating input
character before calling READ (else 376 is returned as 3 (read succeeds
early)).
next, i have to throw away the key-press event from the event queue
since it was requeued by exiting the first event-case
then, i use the condition system to keep READ safe from errors and
attempt a READ on the buffer. If READ succeeds (it might be reading
a partial list and fail) then I return the result, else I continue.
I understand that this is incredibly clanky but X-Windows wants me
to write my program as an EVENT-CASE structure and other window
systems will allow READs to windows. My code is designed to port
to other window systems.
One (flame-like) comment: X-Windows is designed as a policy-free
window system but it strongly constrains the designs of programs
that use it. Methinks this might need discussion.
Tim
DALY@IBM.COM
IBM T.J.Watson Research Center
Yorktown Heights, N.Y. 10598
------- End undelivered message -------
∂02-Dec-88 0704 Mailer failed mail returned
To: CL-Windows-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
puccio@MEDIA-LAB.MEDIA.MIT.EDU; weissman@apollo.com; hultquis@prandtl.nas.nasa.gov; lispx-gmd@gmdzi.uucp@UUNET.UU.NET; eric@SCUBED.ARPA; MARSHALL%PLU@IO.ARC.NASA.GOV; TAYLOR%PLU@IO.ARC.NASA.GOV; York@Chuck-Jones.ILA-West.Dialnet.Symbolics.COM; in-cl-windows@jimi.cs.unlv.edu
Here is how the remote host(s) replied to these mail addresses:
puccio@MEDIA-LAB.MEDIA.MIT.EDU
550 <puccio@MEDIA-LAB.MEDIA.MIT.EDU>... User unknown
lispx-gmd@gmdzi.uucp@UUNET.UU.NET
550 <"lispx-gmd@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
tk%moss@ATT.ARPA
421 research.att.com too busy, please try later
blewett%research.att.com%siriusb@RESEARCH.ATT.COM
421 research.att.com too busy, please try later
------- Begin undelivered message: -------
02-Dec-88 0704 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from forsythe.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:04:51 PST
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 07:04:42 PST
Received: from FINHUTC.HUT.FI by Finhutc.HUT.FI (Mailer R2.01) with BSMTP id
5441; Fri, 02 Dec 88 16:50:42 EET
Received: from santra.hut.fi by FINHUTC.HUT.FI ; 2 Dec 88 16:50:41 EET
Received: from hutcs.hut.fi by santra.hut.fi
(5.57/ida/6.8/TeKoLa) id AA28692; Fri, 2 Dec 88 08:56:57 +0200
Received: by hutcs.hut.fi (5.57/ida/6.6/S-TeKoLa)
id AA01081; Fri, 2 Dec 88 08:59:36 +0200
Date: Fri, 2 Dec 88 08:59:36 +0200
From: Jussi Opas <jho%hutcs.hut.fi@Forsythe.Stanford.EDU>
Message-Id: <8812020659.AA01081@hutcs.hut.fi>
To: cl-windows@sail.stanford.edu, clue-review@dsg.csc.ti.com
Subject: Other-LISP-versions-of-CLUE
Now, do somebody know, whether CLUE has been run
succesfully in other versions of LISP. Such as Lucid or KCL.
If yes, then who and where. If not, the why.
A fast response expected.
Jussi Opas
Helsinki University of technology
Laboratory of Information Processing Science
Otakaari 1 A
02150 Espoo 15
Finland
mail addresses: jho%hutcs.uucp@fingate.bitnet
uuco:mcvax!hutcs!jho
internet:jho@hutcs.hut.fi
------- End undelivered message -------
∂02-Dec-88 0816 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:16:41 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA26143; Fri, 2 Dec 88 08:15:28 PST
Date: Fri, 2 Dec 88 08:15:28 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8812021615.AA26143@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA26138; Fri, 2 Dec 88 08:15:28 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14162; Fri, 2 Dec 88 08:15:31 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST
Date: Fri, 2 Dec 88 11:02 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: commonlisp types
To: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812020545.AA12869@Think.COM>
Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
I think this means that they didn't want to create confusion about
whether the lambda expressions produced lexical closures or not.
Someone might think that the following would work:
(defun strange-eq (x y)
(typep x '(satisfies (lambda (object) (eq object y)))))
barmar
∂02-Dec-88 0826 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:26:06 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA26343; Fri, 2 Dec 88 08:25:02 PST
Date: Fri, 2 Dec 88 08:25:02 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8812021625.AA26343@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA26336; Fri, 2 Dec 88 08:25:02 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14236; Fri, 2 Dec 88 08:25:01 PST
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:10:16 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 08:09:07 PST
Received: by ibuki.UUCP (5.52/4.7)
id AA12633; Thu, 1 Dec 88 15:50:57 PST
Date: Thu, 1 Dec 88 15:50:57 PST
From: ibuki!dbp@labrea.stanford.edu (David Posner)
Message-Id: <8812012350.AA12633@ibuki.UUCP>
To: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
Some comments on John Foderaro's comments on "C-based" Lisps
This is in response John Foderaro's comments on "C based" Lisps on the
Sun 4. (IBUKI Common Lisp, a derivative of Kyoto Common Lisp, is such
a "C based" lisp.) First, a general remark, comparisons with Franz Lisp
are simply not valid. Professors Yuasa and Hagiya, the original designers
of KCL, had the benefit of 3 decades of work on Lisp implementation and
compiler development (including Franz Lisp and all the more recent work
on compiler technology) on which to base their work. They knew all of
this technology. In addition they are first class computer scientists
and awesome hackers. They were extremely concerned with performance
and they built a system which competes quite favorably with "direct"
implementations. (John should consider not what he did those many years
ago but rather what he would be capable of doing today.)
With respect to John's specific comments.
1) The use of global registers on the Sun 4.
"The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asynchronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp."
Allegro seem to have 4 uses for the global registers:
(a) pointing to a "global function table";
(b) asynchronous interrupt "tracking";
(c) nil testing.
(d) multiple value handling;
(a) is not necessary. I assume that the "global function table" is a transfer
vector used to call Allegro kernel functions. In IBCL and KCL calls to
kernel functions are directly linked and so there is no need to call indirect
through a transfer vector. (This is in fact an implicit win for the C based
Lisps.)
(b) is of marginal value. As I recall, The Allegro compiler inserts code
to poll for interrupts in which case the register is obviously of value. The
only interrupt polling in IBCL however occurs when entering critical sections.
(c) is of marginal value. Not having nil in a register costs at most a couple
of cycles in doing a nil test (2 immediate instructions to build the constant.)
The only case in which this could possibly be significant is in an extremely
tight loop but in that case the IBCL back-end optimizer (the C-compiler!) can
simply reserve a register for nil and store nil once on loop entry.
(d) is hard to assess because I do not know much about how Allegro handles
multiple values and lambda list parsing. Conceivably this could amount to
a few percent in function call intensive code. The next release of IBCL will
include considerable performance enhancements for function calling. (One of
the beauties of the original work at Kyoto is the modularity and extensibility
of the implementation -- in particular the compiler.)
In short I strongly doubt that Allegro's use of global registers gives it
anything more than a marginal advantage over the C based Lisps.
(2) The ability to exploit tagged arithmetic. IBCL and KCL do not currently
do any open coding of generic arithmetic. This loses when generic
operators are used to do fixnum arithmetic. IBCL will be making considerable
improvements in this area in its next release but even so in most cases the
right thing to do is to use fixnum operators to do fixnum arithmetic, and
floating point operators to do floating point arithmetic, i.e., add
appropriate type declarations to the code. When declarations are in place
IBCL and KCL compile Lisp arithmetic to equivalent C arithmetic and from
that point it is doubtful that the Allegro compiler will do better than the
optimizing C-compiler.
I would like to add an Amen to Jim McDonald's points about benchmarking
and interpretation of benchmarks. [I saw an ad recently touting one lisp
as running "23% faster" than another on the Gabriels (except it didn't call
them that) without any explanation of how the benchmarks were made and
how they summarized the results.] Advertized benchmarks are typically
run on stand alone maxed out hardware. On real systems the small size
of the C based Lisps (the total image size is about 2 megs
including compiler) is likely to be just as important as how registers
get used.
Another area where "C-based" lisps win is in the ability to tightly integrate
with "foreign" code. IBCL and KCL use the systems object format and their
Lisp data structures are also C data structures. The term "foreign" in this
case is essentially a misnomer.
Another issue that benchmarking doesn't account for is the lead time
between the availability of hardware and the availability of a Lisp.
For the six months or so when IBCL was the only lisp available
on the Sun 4 it might have been reasonable to compare IBCL on a Sun 4
with other Lisps on a Sun 3. This is the current situation on HP
Spectrum series and the MIPS based platforms (e.g., the Silicon Graphics
4D). This will undoubtedly be the situation for the new Apollo and
Motorola based RISCs in the future. In each case the companies
producing direct implementations are going to be in the business of
trying to duplicate all of the back end complexity of the manufacturer's
compilers. With the new architectures the complexity entailed in doing
decent instruction scheduling and register allocation and exploiting
low level parallelism is enormous. I doubt that this duplication
of effort will prove to be cost effective for most applications.
Dave Posner
IBUKI
ibuki!dbp@labrea.stanford.edu
∂02-Dec-88 0828 Mailer@MCC.COM Message of 2-Dec-88 10:27:43
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:28:50 PST
Date: Fri 2 Dec 88 10:27:49-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 2-Dec-88 10:27:43
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Dec 88 10:27:45-CST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST
Date: Fri, 2 Dec 88 11:02 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: commonlisp types
To: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812020545.AA12869@Think.COM>
Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
I think this means that they didn't want to create confusion about
whether the lambda expressions produced lexical closures or not.
Someone might think that the following would work:
(defun strange-eq (x y)
(typep x '(satisfies (lambda (object) (eq object y)))))
barmar
-------
∂02-Dec-88 0830 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:30:15 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14304; Fri, 2 Dec 88 08:29:20 PST
Received: by franz (3.2/3.14)
id AA04645; Fri, 2 Dec 88 08:19:51 PST
Date: Fri, 2 Dec 88 08:19:51 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8812021619.AA04645@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!CL-Windows-mailer
----- Transcript of session follows -----
uux failed. code -1
554 fintail!rfr... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA04643; Fri, 2 Dec 88 08:19:51 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA13753; Fri, 2 Dec 88 07:21:21 PST
Received: from forsythe.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:04:51 PST
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 07:04:42 PST
Received: from FINHUTC.HUT.FI by Finhutc.HUT.FI (Mailer R2.01) with BSMTP id
5441; Fri, 02 Dec 88 16:50:42 EET
Received: from santra.hut.fi by FINHUTC.HUT.FI ; 2 Dec 88 16:50:41 EET
Received: from hutcs.hut.fi by santra.hut.fi
(5.57/ida/6.8/TeKoLa) id AA28692; Fri, 2 Dec 88 08:56:57 +0200
Received: by hutcs.hut.fi (5.57/ida/6.6/S-TeKoLa)
id AA01081; Fri, 2 Dec 88 08:59:36 +0200
Date: Fri, 2 Dec 88 08:59:36 +0200
From: Jussi Opas <ucbarpa!Forsythe.Stanford.EDU!jho%hutcs.hut.fi>
Message-Id: <8812020659.AA01081@hutcs.hut.fi>
To: sail.stanford.edu!cl-windows, dsg.csc.ti.com!clue-review
Subject: Other-LISP-versions-of-CLUE
Now, do somebody know, whether CLUE has been run
succesfully in other versions of LISP. Such as Lucid or KCL.
If yes, then who and where. If not, the why.
A fast response expected.
Jussi Opas
Helsinki University of technology
Laboratory of Information Processing Science
Otakaari 1 A
02150 Espoo 15
Finland
mail addresses: jho%hutcs.uucp@fingate.bitnet
uuco:mcvax!hutcs!jho
internet:jho@hutcs.hut.fi
∂02-Dec-88 0830 franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU Returned mail: unknown mailer error 255
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:30:20 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14309; Fri, 2 Dec 88 08:29:27 PST
Received: by franz (3.2/3.14)
id AA04713; Fri, 2 Dec 88 08:21:30 PST
Date: Fri, 2 Dec 88 08:21:30 PST
From: franz!MAILER-DAEMON@ucbarpa.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: unknown mailer error 255
Message-Id: <8812021621.AA04713@franz>
To: franz!ucbarpa!SAIL.Stanford.EDU!Common-Lisp-mailer
----- Transcript of session follows -----
uux failed. code -1
554 fintail!rfr... unknown mailer error 255
----- Unsent message follows -----
Received: by franz (3.2/3.14)
id AA04702; Fri, 2 Dec 88 08:21:30 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14170; Fri, 2 Dec 88 08:15:39 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST
Date: Fri, 2 Dec 88 11:02 EST
From: Barry Margolin <ucbarpa!Think.COM!barmar>
Subject: Re: commonlisp types
To: Jamie.Zawinski <spice.cs.cmu.edu!jwz>
Cc: sail.stanford.edu!common-lisp
In-Reply-To: <8812020545.AA12869@Think.COM>
Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
I think this means that they didn't want to create confusion about
whether the lambda expressions produced lexical closures or not.
Someone might think that the following would work:
(defun strange-eq (x y)
(typep x '(satisfies (lambda (object) (eq object y)))))
barmar
∂02-Dec-88 0833 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: User unknown
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:33:16 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA10524; Fri, 2 Dec 88 11:32:38 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AB14513; Fri, 2 Dec 88 11:18:56 EST
Date: Fri, 2 Dec 88 11:18:56 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <8812021618.AB14513@cvbnet.prime.com>
To: Common-Lisp-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 qfAA14338: line 18: basie!tbardasz... No known UUCP connection to basie
550 Postmaster... User unknown
----- Unsent message follows -----
Return-Path: <SAIL.Stanford.EDU!Common-Lisp-mailer@decvax.uucp>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA14338; Fri, 2 Dec 88 10:40:02 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA00997; Thu, 1 Dec 88 22:18:15 PST
Message-Id: <8812020618.AA00997@decwrl.dec.com>
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:04:56 PST
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <spice.cs.cmu.edu!jwz@decvax.uucp>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
...but I believe it is the case that there is no CL way to determine
if a given type is defined.
I wish there was some CL way to define a complex type and insert it in
the existing hierarchy. For example, I once tried to define the type
LIST-OF, which would be used like
(TYPEP '(1 2 3) '(LIST-OF FIXNUM)) ==> T
(TYPEP '(A B 3) '(LIST-OF FIXNUM)) ==> NIL
(SUBTYPEP '(LIST-OF SYMBOL) 'LIST) ==> T
(SUBTYPEP '(LIST-OF FIXNUM) '(LIST-OF NUMBER)) ==> T
(SUBTYPEP '(LIST-OF *) '(LIST-OF LIST)) ==> NIL NIL
On the TI Explorer this was really easy.
In Lucid CL, it was not possible except by bashing the definitions of
TYPEP and SUBTYPEP.
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Jamie
∂02-Dec-88 0833 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: User unknown
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:33:37 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA10531; Fri, 2 Dec 88 11:33:00 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AB14513; Fri, 2 Dec 88 11:19:03 EST
Date: Fri, 2 Dec 88 11:19:03 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <8812021619.AB14513@cvbnet.prime.com>
To: CL-Windows-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 qfAA14374: line 26: basie!tbardasz... No known UUCP connection to basie
550 Postmaster... User unknown
----- Unsent message follows -----
Return-Path: <SAIL.Stanford.EDU!CL-Windows-mailer@decvax.uucp>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA14374; Fri, 2 Dec 88 10:45:00 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA24499; Fri, 2 Dec 88 07:22:25 PST
Received: from forsythe.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:04:51 PST
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 07:04:42 PST
Received: from FINHUTC.HUT.FI by Finhutc.HUT.FI (Mailer R2.01) with BSMTP id
5441; Fri, 02 Dec 88 16:50:42 EET
Received: from santra.hut.fi by FINHUTC.HUT.FI ; 2 Dec 88 16:50:41 EET
Received: from hutcs.hut.fi by santra.hut.fi
(5.57/ida/6.8/TeKoLa) id AA28692; Fri, 2 Dec 88 08:56:57 +0200
Received: by hutcs.hut.fi (5.57/ida/6.6/S-TeKoLa)
id AA01081; Fri, 2 Dec 88 08:59:36 +0200
Date: Fri, 2 Dec 88 08:59:36 +0200
From: Jussi Opas <decvax!Forsythe.Stanford.EDU!jho@hutcs.hut.fi>
Message-Id: <8812020659.AA01081@hutcs.hut.fi>
To: cl-windows@sail.stanford.edu, clue-review@dsg.csc.ti.com
Subject: Other-LISP-versions-of-CLUE
Now, do somebody know, whether CLUE has been run
succesfully in other versions of LISP. Such as Lucid or KCL.
If yes, then who and where. If not, the why.
A fast response expected.
Jussi Opas
Helsinki University of technology
Laboratory of Information Processing Science
Otakaari 1 A
02150 Espoo 15
Finland
mail addresses: jho%hutcs.uucp@fingate.bitnet
uuco:mcvax!hutcs!jho
internet:jho@hutcs.hut.fi
∂02-Dec-88 0836 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: User unknown
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:34:10 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA10539; Fri, 2 Dec 88 11:33:27 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AD14513; Fri, 2 Dec 88 11:19:08 EST
Date: Fri, 2 Dec 88 11:19:08 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <8812021619.AD14513@cvbnet.prime.com>
To: CL-Windows-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 qfAA14382: line 18: basie!tbardasz... No known UUCP connection to basie
550 Postmaster... User unknown
----- Unsent message follows -----
Return-Path: <SAIL.Stanford.EDU!CL-Windows-mailer@decvax.uucp>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA14382; Fri, 2 Dec 88 10:45:07 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA24659; Fri, 2 Dec 88 07:26:00 PST
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:08:56 PST
Date: 1 Dec 88 11:06:47 EST
From: Timothy Daly <ibm.com!DALY@decvax.uucp>
To: cl-windows@sail.stanford.edu
Message-Id: <120188.110651.daly@ibm.com>
Subject: streams to common lisp windows.
Well, I HAVE succeeded in implementing a function that will return
the READ of a window. It is truly ugly but it works. The essential
steps are:
catch :exit
event-case to capture keycodes (NOT ascii)
when :key-press
convert key to ascii
when key is of type character
concat to buffer
if key is a constituent char
then exit event-case
else continue event-case
event-case to throw away the key event (discard-p t)
condition-case (with-input-from-string (s buffer) (setq result (read s)))
on simple-condition-error (setq result :fail)
unless (eq result :fail) (throw :exit result)
essentially, i capture each key-press event, convert it to ascii,
and if it is an ascii character I add it to the buffer. The constituent
character check is there to wait until there is some terminating input
character before calling READ (else 376 is returned as 3 (read succeeds
early)).
next, i have to throw away the key-press event from the event queue
since it was requeued by exiting the first event-case
then, i use the condition system to keep READ safe from errors and
attempt a READ on the buffer. If READ succeeds (it might be reading
a partial list and fail) then I return the result, else I continue.
I understand that this is incredibly clanky but X-Windows wants me
to write my program as an EVENT-CASE structure and other window
systems will allow READs to windows. My code is designed to port
to other window systems.
One (flame-like) comment: X-Windows is designed as a policy-free
window system but it strongly constrains the designs of programs
that use it. Methinks this might need discussion.
Tim
DALY@IBM.COM
IBM T.J.Watson Research Center
Yorktown Heights, N.Y. 10598
∂02-Dec-88 0837 Mail Delivery Problem
Received: from amrf (amrf.cme.nbs.gov) by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:55 PST
Date: 2 Dec 88 11:15:08 EST
From: "SMTP MAILER" <postmaster@amrf>
Subject: Mail Delivery Problem
To: <cl-windows-mailer@sail.stanford.edu>
----Reason for mail failure follows----
Sending mail to recipient(s) meunier :
Couldn't make final delivery.
----Transcript of message follows----
Received: from SAIL.Stanford.EDU by amrf with SMTP ; Fri, 2 Dec 88 10:57:19 EST
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:08:56 PST
Date: 1 Dec 88 11:06:47 EST
From: Timothy Daly <DALY@ibm.com>
To: cl-windows@sail.stanford.edu
Message-Id: <120188.110651.daly@ibm.com>
Subject: streams to common lisp windows.
Well, I HAVE succeeded in implementing a function that will return
the READ of a window. It is truly ugly but it works. The essential
steps are:
catch :exit
event-case to capture keycodes (NOT ascii)
when :key-press
convert key to ascii
when key is of type character
concat to buffer
if key is a constituent char
then exit event-case
else continue event-case
event-case to throw away the key event (discard-p t)
condition-case (with-input-from-string (s buffer) (setq result (read s)))
on simple-condition-error (setq result :fail)
unless (eq result :fail) (throw :exit result)
essentially, i capture each key-press event, convert it to ascii,
and if it is an ascii character I add it to the buffer. The constituent
character check is there to wait until there is some terminating input
character before calling READ (else 376 is returned as 3 (read succeeds
early)).
next, i have to throw away the key-press event from the event queue
since it was requeued by exiting the first event-case
then, i use the condition system to keep READ safe from errors and
attempt a READ on the buffer. If READ succeeds (it might be reading
a partial list and fail) then I return the result, else I continue.
I understand that this is incredibly clanky but X-Windows wants me
to write my program as an EVENT-CASE structure and other window
systems will allow READs to windows. My code is designed to port
to other window systems.
One (flame-like) comment: X-Windows is designed as a policy-free
window system but it strongly constrains the designs of programs
that use it. Methinks this might need discussion.
Tim
DALY@IBM.COM
IBM T.J.Watson Research Center
Yorktown Heights, N.Y. 10598
∂02-Dec-88 0838 Mailer@MCC.COM Message of 2-Dec-88 10:37:11
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:38:43 PST
Date: Fri 2 Dec 88 10:37:22-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 2-Dec-88 10:37:11
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Dec 88 10:37:12-CST
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:10:16 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 08:09:07 PST
Received: by ibuki.UUCP (5.52/4.7)
id AA12633; Thu, 1 Dec 88 15:50:57 PST
Date: Thu, 1 Dec 88 15:50:57 PST
From: ibuki!dbp@labrea.stanford.edu (David Posner)
Message-Id: <8812012350.AA12633@ibuki.UUCP>
To: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
Some comments on John Foderaro's comments on "C-based" Lisps
This is in response John Foderaro's comments on "C based" Lisps on the
Sun 4. (IBUKI Common Lisp, a derivative of Kyoto Common Lisp, is such
a "C based" lisp.) First, a general remark, comparisons with Franz Lisp
are simply not valid. Professors Yuasa and Hagiya, the original designers
of KCL, had the benefit of 3 decades of work on Lisp implementation and
compiler development (including Franz Lisp and all the more recent work
on compiler technology) on which to base their work. They knew all of
this technology. In addition they are first class computer scientists
and awesome hackers. They were extremely concerned with performance
and they built a system which competes quite favorably with "direct"
implementations. (John should consider not what he did those many years
ago but rather what he would be capable of doing today.)
With respect to John's specific comments.
1) The use of global registers on the Sun 4.
"The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asynchronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp."
Allegro seem to have 4 uses for the global registers:
(a) pointing to a "global function table";
(b) asynchronous interrupt "tracking";
(c) nil testing.
(d) multiple value handling;
(a) is not necessary. I assume that the "global function table" is a transfer
vector used to call Allegro kernel functions. In IBCL and KCL calls to
kernel functions are directly linked and so there is no need to call indirect
through a transfer vector. (This is in fact an implicit win for the C based
Lisps.)
(b) is of marginal value. As I recall, The Allegro compiler inserts code
to poll for interrupts in which case the register is obviously of value. The
only interrupt polling in IBCL however occurs when entering critical sections.
(c) is of marginal value. Not having nil in a register costs at most a couple
of cycles in doing a nil test (2 immediate instructions to build the constant.)
The only case in which this could possibly be significant is in an extremely
tight loop but in that case the IBCL back-end optimizer (the C-compiler!) can
simply reserve a register for nil and store nil once on loop entry.
(d) is hard to assess because I do not know much about how Allegro handles
multiple values and lambda list parsing. Conceivably this could amount to
a few percent in function call intensive code. The next release of IBCL will
include considerable performance enhancements for function calling. (One of
the beauties of the original work at Kyoto is the modularity and extensibility
of the implementation -- in particular the compiler.)
In short I strongly doubt that Allegro's use of global registers gives it
anything more than a marginal advantage over the C based Lisps.
(2) The ability to exploit tagged arithmetic. IBCL and KCL do not currently
do any open coding of generic arithmetic. This loses when generic
operators are used to do fixnum arithmetic. IBCL will be making considerable
improvements in this area in its next release but even so in most cases the
right thing to do is to use fixnum operators to do fixnum arithmetic, and
floating point operators to do floating point arithmetic, i.e., add
appropriate type declarations to the code. When declarations are in place
IBCL and KCL compile Lisp arithmetic to equivalent C arithmetic and from
that point it is doubtful that the Allegro compiler will do better than the
optimizing C-compiler.
I would like to add an Amen to Jim McDonald's points about benchmarking
and interpretation of benchmarks. [I saw an ad recently touting one lisp
as running "23% faster" than another on the Gabriels (except it didn't call
them that) without any explanation of how the benchmarks were made and
how they summarized the results.] Advertized benchmarks are typically
run on stand alone maxed out hardware. On real systems the small size
of the C based Lisps (the total image size is about 2 megs
including compiler) is likely to be just as important as how registers
get used.
Another area where "C-based" lisps win is in the ability to tightly integrate
with "foreign" code. IBCL and KCL use the systems object format and their
Lisp data structures are also C data structures. The term "foreign" in this
case is essentially a misnomer.
Another issue that benchmarking doesn't account for is the lead time
between the availability of hardware and the availability of a Lisp.
For the six months or so when IBCL was the only lisp available
on the Sun 4 it might have been reasonable to compare IBCL on a Sun 4
with other Lisps on a Sun 3. This is the current situation on HP
Spectrum series and the MIPS based platforms (e.g., the Silicon Graphics
4D). This will undoubtedly be the situation for the new Apollo and
Motorola based RISCs in the future. In each case the companies
producing direct implementations are going to be in the business of
trying to duplicate all of the back end complexity of the manufacturer's
compilers. With the new architectures the complexity entailed in doing
decent instruction scheduling and register allocation and exploiting
low level parallelism is enormous. I doubt that this duplication
of effort will prove to be cost effective for most applications.
Dave Posner
IBUKI
ibuki!dbp@labrea.stanford.edu
-------
∂02-Dec-88 0837 Mail Delivery Problem
Received: from amrf (amrf.cme.nbs.gov) by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:37:02 PST
Date: 2 Dec 88 11:15:10 EST
From: "SMTP MAILER" <postmaster@amrf>
Subject: Mail Delivery Problem
To: <cl-windows-mailer@sail.stanford.edu>
----Reason for mail failure follows----
Sending mail to recipient(s) meunier :
Couldn't make final delivery.
----Transcript of message follows----
Received: from SAIL.Stanford.EDU by amrf with SMTP ; Fri, 2 Dec 88 10:56:55 EST
Received: from forsythe.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:04:51 PST
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 07:04:42 PST
Received: from FINHUTC.HUT.FI by Finhutc.HUT.FI (Mailer R2.01) with BSMTP id
5441; Fri, 02 Dec 88 16:50:42 EET
Received: from santra.hut.fi by FINHUTC.HUT.FI ; 2 Dec 88 16:50:41 EET
Received: from hutcs.hut.fi by santra.hut.fi
(5.57/ida/6.8/TeKoLa) id AA28692; Fri, 2 Dec 88 08:56:57 +0200
Received: by hutcs.hut.fi (5.57/ida/6.6/S-TeKoLa)
id AA01081; Fri, 2 Dec 88 08:59:36 +0200
Date: Fri, 2 Dec 88 08:59:36 +0200
From: Jussi Opas <jho%hutcs.hut.fi@Forsythe.Stanford.EDU>
Message-Id: <8812020659.AA01081@hutcs.hut.fi>
To: cl-windows@sail.stanford.edu, clue-review@dsg.csc.ti.com
Subject: Other-LISP-versions-of-CLUE
Now, do somebody know, whether CLUE has been run
succesfully in other versions of LISP. Such as Lucid or KCL.
If yes, then who and where. If not, the why.
A fast response expected.
Jussi Opas
Helsinki University of technology
Laboratory of Information Processing Science
Otakaari 1 A
02150 Espoo 15
Finland
mail addresses: jho%hutcs.uucp@fingate.bitnet
uuco:mcvax!hutcs!jho
internet:jho@hutcs.hut.fi
∂02-Dec-88 0846 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: Unable to deliver mail
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:46:21 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA10682; Fri, 2 Dec 88 11:45:50 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AC14704; Fri, 2 Dec 88 11:46:30 EST
Date: Fri, 2 Dec 88 11:46:30 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8812021646.AC14704@cvbnet.prime.com>
To: Common-Lisp-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 basie!tbardasz... No known UUCP connection to basie
554 decvax!SAIL.Stanford.EDU!Common-Lisp-mailer... Possible alias loop
554 No valid recipients
----- Unsent message follows -----
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA14704; Fri, 2 Dec 88 11:46:30 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA27458; Fri, 2 Dec 88 08:16:41 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST
Date: Fri, 2 Dec 88 11:02 EST
From: Barry Margolin <Think.COM!barmar@decvax.uucp>
Subject: Re: commonlisp types
To: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812020545.AA12869@Think.COM>
Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
I think this means that they didn't want to create confusion about
whether the lambda expressions produced lexical closures or not.
Someone might think that the following would work:
(defun strange-eq (x y)
(typep x '(satisfies (lambda (object) (eq object y)))))
barmar
∂02-Dec-88 0849 MAILER-DAEMON@ucbvax.Berkeley.EDU Returned mail: Host unknown
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:49:22 PST
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA26775; Fri, 2 Dec 88 08:48:14 PST
Date: Fri, 2 Dec 88 08:48:14 PST
From: MAILER-DAEMON@ucbvax.Berkeley.EDU (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <8812021648.AA26775@ucbvax.Berkeley.EDU>
To: <Common-Lisp-mailer@SAIL.Stanford.EDU>
----- Transcript of session follows -----
550 <dual!well!saint>... Host unknown
----- Unsent message follows -----
Received: from ucbarpa.Berkeley.EDU by ucbvax.Berkeley.EDU (5.61/1.31)
id AA26772; Fri, 2 Dec 88 08:48:14 PST
Received: from Sail.Stanford.EDU by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA14573; Fri, 2 Dec 88 08:48:14 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:41 PST
Received: from fafnir.think.com by Think.COM; Fri, 2 Dec 88 11:13:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 2 Dec 88 11:34:51 EST
Received: by verdi.think.com; Fri, 2 Dec 88 11:33:22 EST
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812021633.AA05964@verdi.think.com>
To: jwz@spice.cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Jamie.Zawinski's message of Fri, 2 Dec 1988 00:40-EST <8812020545.AA12869@Think.COM>
Subject: commonlisp types
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Consider
(defun bazola (linguini pop-tarts)
(declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
...)
I'm trying to say that pop-tarts is always smaller in value than linguini.
The lambda expression appears lexically within the binding of linguini,
so one might expect that the free reference to linguini is legitimate.
But it can't work.
Similarly this cannot work:
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
...)
[Of course, this can be rendered instead as
(defun bazola (linguini pop-tarts)
(assert (< pop-tarts linguini))
...)
but that is beside the point.]
One might conceivably argue that SATISFIES should allow an actual
function and not just a name; then one might try
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
...)
but this approach doesn't help the declaration case. It's a basic problem
of compile-time versus run-time execution.
--Guy
∂02-Dec-88 0804 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; yang%softy.DEC@decwrl.ARPA; common-lisp@gmdzi.uucp@UUNET.UU.NET
Here is how the remote host(s) replied to these mail addresses:
toad@NL.CS.CMU.EDU
450 Internal error forking to deliver mail
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
02-Dec-88 0804 Common-Lisp-mailer Re: commonlisp types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST
Date: Fri, 2 Dec 88 11:02 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: commonlisp types
To: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812020545.AA12869@Think.COM>
Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
I think this means that they didn't want to create confusion about
whether the lambda expressions produced lexical closures or not.
Someone might think that the following would work:
(defun strange-eq (x y)
(typep x '(satisfies (lambda (object) (eq object y)))))
barmar
------- End undelivered message -------
∂02-Dec-88 0901 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: Unable to deliver mail
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:01:19 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA10769; Fri, 2 Dec 88 12:00:40 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AC14723; Fri, 2 Dec 88 11:48:19 EST
Date: Fri, 2 Dec 88 11:48:19 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8812021648.AC14723@cvbnet.prime.com>
To: Common-Lisp-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 basie!tbardasz... No known UUCP connection to basie
554 decvax!SAIL.Stanford.EDU!Common-Lisp-mailer... Possible alias loop
554 No valid recipients
----- Unsent message follows -----
Return-Path: <SAIL.Stanford.EDU!Common-Lisp-mailer@decvax.uucp>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA14723; Fri, 2 Dec 88 11:48:19 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA28082; Fri, 2 Dec 88 08:25:56 PST
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:10:16 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 08:09:07 PST
Received: by ibuki.UUCP (5.52/4.7)
id AA12633; Thu, 1 Dec 88 15:50:57 PST
Date: Thu, 1 Dec 88 15:50:57 PST
From: decwrl!labrea.stanford.edu!ibuki!dbp@decvax.uucp (David Posner)
Message-Id: <8812012350.AA12633@ibuki.UUCP>
To: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
Some comments on John Foderaro's comments on "C-based" Lisps
This is in response John Foderaro's comments on "C based" Lisps on the
Sun 4. (IBUKI Common Lisp, a derivative of Kyoto Common Lisp, is such
a "C based" lisp.) First, a general remark, comparisons with Franz Lisp
are simply not valid. Professors Yuasa and Hagiya, the original designers
of KCL, had the benefit of 3 decades of work on Lisp implementation and
compiler development (including Franz Lisp and all the more recent work
on compiler technology) on which to base their work. They knew all of
this technology. In addition they are first class computer scientists
and awesome hackers. They were extremely concerned with performance
and they built a system which competes quite favorably with "direct"
implementations. (John should consider not what he did those many years
ago but rather what he would be capable of doing today.)
With respect to John's specific comments.
1) The use of global registers on the Sun 4.
"The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asynchronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp."
Allegro seem to have 4 uses for the global registers:
(a) pointing to a "global function table";
(b) asynchronous interrupt "tracking";
(c) nil testing.
(d) multiple value handling;
(a) is not necessary. I assume that the "global function table" is a transfer
vector used to call Allegro kernel functions. In IBCL and KCL calls to
kernel functions are directly linked and so there is no need to call indirect
through a transfer vector. (This is in fact an implicit win for the C based
Lisps.)
(b) is of marginal value. As I recall, The Allegro compiler inserts code
to poll for interrupts in which case the register is obviously of value. The
only interrupt polling in IBCL however occurs when entering critical sections.
(c) is of marginal value. Not having nil in a register costs at most a couple
of cycles in doing a nil test (2 immediate instructions to build the constant.)
The only case in which this could possibly be significant is in an extremely
tight loop but in that case the IBCL back-end optimizer (the C-compiler!) can
simply reserve a register for nil and store nil once on loop entry.
(d) is hard to assess because I do not know much about how Allegro handles
multiple values and lambda list parsing. Conceivably this could amount to
a few percent in function call intensive code. The next release of IBCL will
include considerable performance enhancements for function calling. (One of
the beauties of the original work at Kyoto is the modularity and extensibility
of the implementation -- in particular the compiler.)
In short I strongly doubt that Allegro's use of global registers gives it
anything more than a marginal advantage over the C based Lisps.
(2) The ability to exploit tagged arithmetic. IBCL and KCL do not currently
do any open coding of generic arithmetic. This loses when generic
operators are used to do fixnum arithmetic. IBCL will be making considerable
improvements in this area in its next release but even so in most cases the
right thing to do is to use fixnum operators to do fixnum arithmetic, and
floating point operators to do floating point arithmetic, i.e., add
appropriate type declarations to the code. When declarations are in place
IBCL and KCL compile Lisp arithmetic to equivalent C arithmetic and from
that point it is doubtful that the Allegro compiler will do better than the
optimizing C-compiler.
I would like to add an Amen to Jim McDonald's points about benchmarking
and interpretation of benchmarks. [I saw an ad recently touting one lisp
as running "23% faster" than another on the Gabriels (except it didn't call
them that) without any explanation of how the benchmarks were made and
how they summarized the results.] Advertized benchmarks are typically
run on stand alone maxed out hardware. On real systems the small size
of the C based Lisps (the total image size is about 2 megs
including compiler) is likely to be just as important as how registers
get used.
Another area where "C-based" lisps win is in the ability to tightly integrate
with "foreign" code. IBCL and KCL use the systems object format and their
Lisp data structures are also C data structures. The term "foreign" in this
case is essentially a misnomer.
Another issue that benchmarking doesn't account for is the lead time
between the availability of hardware and the availability of a Lisp.
For the six months or so when IBCL was the only lisp available
on the Sun 4 it might have been reasonable to compare IBCL on a Sun 4
with other Lisps on a Sun 3. This is the current situation on HP
Spectrum series and the MIPS based platforms (e.g., the Silicon Graphics
4D). This will undoubtedly be the situation for the new Apollo and
Motorola based RISCs in the future. In each case the companies
producing direct implementations are going to be in the business of
trying to duplicate all of the back end complexity of the manufacturer's
compilers. With the new architectures the complexity entailed in doing
decent instruction scheduling and register allocation and exploiting
low level parallelism is enormous. I doubt that this duplication
of effort will prove to be cost effective for most applications.
Dave Posner
IBUKI
ibuki!dbp@labrea.stanford.edu
∂02-Dec-88 0913 Mailer@MCC.COM Message of 2-Dec-88 10:58:38
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:12:39 PST
Date: Fri 2 Dec 88 10:58:49-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: Common-Lisp-mailer@SAIL.STANFORD.EDU
Subject: Message of 2-Dec-88 10:58:38
Message failed for the following:
*PS:<Bboard>Clisp.Txt.1@MCC.COM.#Internet: File not found
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Dec 88 10:58:41-CST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:41 PST
Received: from fafnir.think.com by Think.COM; Fri, 2 Dec 88 11:13:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 2 Dec 88 11:34:51 EST
Received: by verdi.think.com; Fri, 2 Dec 88 11:33:22 EST
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812021633.AA05964@verdi.think.com>
To: jwz@spice.cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Jamie.Zawinski's message of Fri, 2 Dec 1988 00:40-EST <8812020545.AA12869@Think.COM>
Subject: commonlisp types
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Consider
(defun bazola (linguini pop-tarts)
(declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
...)
I'm trying to say that pop-tarts is always smaller in value than linguini.
The lambda expression appears lexically within the binding of linguini,
so one might expect that the free reference to linguini is legitimate.
But it can't work.
Similarly this cannot work:
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
...)
[Of course, this can be rendered instead as
(defun bazola (linguini pop-tarts)
(assert (< pop-tarts linguini))
...)
but that is beside the point.]
One might conceivably argue that SATISFIES should allow an actual
function and not just a name; then one might try
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
...)
but this approach doesn't help the declaration case. It's a basic problem
of compile-time versus run-time execution.
--Guy
-------
∂02-Dec-88 0916 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: Unable to deliver mail
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:15:59 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA10979; Fri, 2 Dec 88 12:15:22 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AC14811; Fri, 2 Dec 88 12:06:10 EST
Date: Fri, 2 Dec 88 12:06:10 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8812021706.AC14811@cvbnet.prime.com>
To: Common-Lisp-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 basie!tbardasz... No known UUCP connection to basie
554 decvax!SAIL.Stanford.EDU!Common-Lisp-mailer... Possible alias loop
554 No valid recipients
----- Unsent message follows -----
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA14811; Fri, 2 Dec 88 12:06:10 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA29348; Fri, 2 Dec 88 08:49:09 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:41 PST
Received: from fafnir.think.com by Think.COM; Fri, 2 Dec 88 11:13:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 2 Dec 88 11:34:51 EST
Received: by verdi.think.com; Fri, 2 Dec 88 11:33:22 EST
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <Think.COM!gls@decvax.uucp>
Message-Id: <8812021633.AA05964@verdi.think.com>
To: jwz@spice.cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Jamie.Zawinski's message of Fri, 2 Dec 1988 00:40-EST <8812020545.AA12869@Think.COM>
Subject: commonlisp types
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Consider
(defun bazola (linguini pop-tarts)
(declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
...)
I'm trying to say that pop-tarts is always smaller in value than linguini.
The lambda expression appears lexically within the binding of linguini,
so one might expect that the free reference to linguini is legitimate.
But it can't work.
Similarly this cannot work:
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
...)
[Of course, this can be rendered instead as
(defun bazola (linguini pop-tarts)
(assert (< pop-tarts linguini))
...)
but that is beside the point.]
One might conceivably argue that SATISFIES should allow an actual
function and not just a name; then one might try
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
...)
but this approach doesn't help the declaration case. It's a basic problem
of compile-time versus run-time execution.
--Guy
∂02-Dec-88 0918 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:17:45 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA13840; Fri, 2 Dec 88 09:16:26 PST
Message-Id: <8812021716.AA13840@trout.nosc.mil>
Date: 2 Dec 88 09:04:34 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Fri Dec 2 08:35:54 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA13363; Fri, 2 Dec 88 08:35:50 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST
Date: Fri, 2 Dec 88 11:02 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: commonlisp types
To: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812020545.AA12869@Think.COM>
Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
I think this means that they didn't want to create confusion about
whether the lambda expressions produced lexical closures or not.
Someone might think that the following would work:
(defun strange-eq (x y)
(typep x '(satisfies (lambda (object) (eq object y)))))
barmar
∂02-Dec-88 0918 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:17:37 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA13851; Fri, 2 Dec 88 09:16:33 PST
Message-Id: <8812021716.AA13851@trout.nosc.mil>
Date: 2 Dec 88 09:04:42 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Fri Dec 2 08:50:15 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA13529; Fri, 2 Dec 88 08:50:10 PST
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:10:16 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 08:09:07 PST
Received: by ibuki.UUCP (5.52/4.7)
id AA12633; Thu, 1 Dec 88 15:50:57 PST
Date: Thu, 1 Dec 88 15:50:57 PST
From: ibuki!dbp@labrea.stanford.edu (David Posner)
Message-Id: <8812012350.AA12633@ibuki.UUCP>
To: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
Some comments on John Foderaro's comments on "C-based" Lisps
This is in response John Foderaro's comments on "C based" Lisps on the
Sun 4. (IBUKI Common Lisp, a derivative of Kyoto Common Lisp, is such
a "C based" lisp.) First, a general remark, comparisons with Franz Lisp
are simply not valid. Professors Yuasa and Hagiya, the original designers
of KCL, had the benefit of 3 decades of work on Lisp implementation and
compiler development (including Franz Lisp and all the more recent work
on compiler technology) on which to base their work. They knew all of
this technology. In addition they are first class computer scientists
and awesome hackers. They were extremely concerned with performance
and they built a system which competes quite favorably with "direct"
implementations. (John should consider not what he did those many years
ago but rather what he would be capable of doing today.)
With respect to John's specific comments.
1) The use of global registers on the Sun 4.
"The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asynchronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp."
Allegro seem to have 4 uses for the global registers:
(a) pointing to a "global function table";
(b) asynchronous interrupt "tracking";
(c) nil testing.
(d) multiple value handling;
(a) is not necessary. I assume that the "global function table" is a transfer
vector used to call Allegro kernel functions. In IBCL and KCL calls to
kernel functions are directly linked and so there is no need to call indirect
through a transfer vector. (This is in fact an implicit win for the C based
Lisps.)
(b) is of marginal value. As I recall, The Allegro compiler inserts code
to poll for interrupts in which case the register is obviously of value. The
only interrupt polling in IBCL however occurs when entering critical sections.
(c) is of marginal value. Not having nil in a register costs at most a couple
of cycles in doing a nil test (2 immediate instructions to build the constant.)
The only case in which this could possibly be significant is in an extremely
tight loop but in that case the IBCL back-end optimizer (the C-compiler!) can
simply reserve a register for nil and store nil once on loop entry.
(d) is hard to assess because I do not know much about how Allegro handles
multiple values and lambda list parsing. Conceivably this could amount to
a few percent in function call intensive code. The next release of IBCL will
include considerable performance enhancements for function calling. (One of
the beauties of the original work at Kyoto is the modularity and extensibility
of the implementation -- in particular the compiler.)
In short I strongly doubt that Allegro's use of global registers gives it
anything more than a marginal advantage over the C based Lisps.
(2) The ability to exploit tagged arithmetic. IBCL and KCL do not currently
do any open coding of generic arithmetic. This loses when generic
operators are used to do fixnum arithmetic. IBCL will be making considerable
improvements in this area in its next release but even so in most cases the
right thing to do is to use fixnum operators to do fixnum arithmetic, and
floating point operators to do floating point arithmetic, i.e., add
appropriate type declarations to the code. When declarations are in place
IBCL and KCL compile Lisp arithmetic to equivalent C arithmetic and from
that point it is doubtful that the Allegro compiler will do better than the
optimizing C-compiler.
I would like to add an Amen to Jim McDonald's points about benchmarking
and interpretation of benchmarks. [I saw an ad recently touting one lisp
as running "23% faster" than another on the Gabriels (except it didn't call
them that) without any explanation of how the benchmarks were made and
how they summarized the results.] Advertized benchmarks are typically
run on stand alone maxed out hardware. On real systems the small size
of the C based Lisps (the total image size is about 2 megs
including compiler) is likely to be just as important as how registers
get used.
Another area where "C-based" lisps win is in the ability to tightly integrate
with "foreign" code. IBCL and KCL use the systems object format and their
Lisp data structures are also C data structures. The term "foreign" in this
case is essentially a misnomer.
Another issue that benchmarking doesn't account for is the lead time
between the availability of hardware and the availability of a Lisp.
For the six months or so when IBCL was the only lisp available
on the Sun 4 it might have been reasonable to compare IBCL on a Sun 4
with other Lisps on a Sun 3. This is the current situation on HP
Spectrum series and the MIPS based platforms (e.g., the Silicon Graphics
4D). This will undoubtedly be the situation for the new Apollo and
Motorola based RISCs in the future. In each case the companies
producing direct implementations are going to be in the business of
trying to duplicate all of the back end complexity of the manufacturer's
compilers. With the new architectures the complexity entailed in doing
decent instruction scheduling and register allocation and exploiting
low level parallelism is enormous. I doubt that this duplication
of effort will prove to be cost effective for most applications.
Dave Posner
IBUKI
ibuki!dbp@labrea.stanford.edu
∂02-Dec-88 0918 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:17:49 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA13823; Fri, 2 Dec 88 09:16:14 PST
Message-Id: <8812021716.AA13823@trout.nosc.mil>
Date: 2 Dec 88 09:04:05 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Thu Dec 1 18:25:22 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27418; Thu, 1 Dec 88 18:25:07 PST
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:56:05 PST
Posted-Date: Wed, 30 Nov 88 18:55:38 PST
Message-Id: <8812010255.AA17146@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA17146; Wed, 30 Nov 88 18:55:41 PST
To: common-lisp@sail.stanford.edu
Subject: commonlisp types
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
∂02-Dec-88 0810 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; yang%softy.DEC@decwrl.ARPA; common-lisp@gmdzi.uucp@UUNET.UU.NET; raible@AMES-NAS.ARPA
Here is how the remote host(s) replied to these mail addresses:
toad@NL.CS.CMU.EDU
450 Internal error forking to deliver mail
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
02-Dec-88 0810 Common-Lisp-mailer Re: Common Lisp for SUNS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:10:16 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 08:09:07 PST
Received: by ibuki.UUCP (5.52/4.7)
id AA12633; Thu, 1 Dec 88 15:50:57 PST
Date: Thu, 1 Dec 88 15:50:57 PST
From: ibuki!dbp@labrea.stanford.edu (David Posner)
Message-Id: <8812012350.AA12633@ibuki.UUCP>
To: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
Some comments on John Foderaro's comments on "C-based" Lisps
This is in response John Foderaro's comments on "C based" Lisps on the
Sun 4. (IBUKI Common Lisp, a derivative of Kyoto Common Lisp, is such
a "C based" lisp.) First, a general remark, comparisons with Franz Lisp
are simply not valid. Professors Yuasa and Hagiya, the original designers
of KCL, had the benefit of 3 decades of work on Lisp implementation and
compiler development (including Franz Lisp and all the more recent work
on compiler technology) on which to base their work. They knew all of
this technology. In addition they are first class computer scientists
and awesome hackers. They were extremely concerned with performance
and they built a system which competes quite favorably with "direct"
implementations. (John should consider not what he did those many years
ago but rather what he would be capable of doing today.)
With respect to John's specific comments.
1) The use of global registers on the Sun 4.
"The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asynchronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp."
Allegro seem to have 4 uses for the global registers:
(a) pointing to a "global function table";
(b) asynchronous interrupt "tracking";
(c) nil testing.
(d) multiple value handling;
(a) is not necessary. I assume that the "global function table" is a transfer
vector used to call Allegro kernel functions. In IBCL and KCL calls to
kernel functions are directly linked and so there is no need to call indirect
through a transfer vector. (This is in fact an implicit win for the C based
Lisps.)
(b) is of marginal value. As I recall, The Allegro compiler inserts code
to poll for interrupts in which case the register is obviously of value. The
only interrupt polling in IBCL however occurs when entering critical sections.
(c) is of marginal value. Not having nil in a register costs at most a couple
of cycles in doing a nil test (2 immediate instructions to build the constant.)
The only case in which this could possibly be significant is in an extremely
tight loop but in that case the IBCL back-end optimizer (the C-compiler!) can
simply reserve a register for nil and store nil once on loop entry.
(d) is hard to assess because I do not know much about how Allegro handles
multiple values and lambda list parsing. Conceivably this could amount to
a few percent in function call intensive code. The next release of IBCL will
include considerable performance enhancements for function calling. (One of
the beauties of the original work at Kyoto is the modularity and extensibility
of the implementation -- in particular the compiler.)
In short I strongly doubt that Allegro's use of global registers gives it
anything more than a marginal advantage over the C based Lisps.
(2) The ability to exploit tagged arithmetic. IBCL and KCL do not currently
do any open coding of generic arithmetic. This loses when generic
operators are used to do fixnum arithmetic. IBCL will be making considerable
improvements in this area in its next release but even so in most cases the
right thing to do is to use fixnum operators to do fixnum arithmetic, and
floating point operators to do floating point arithmetic, i.e., add
appropriate type declarations to the code. When declarations are in place
IBCL and KCL compile Lisp arithmetic to equivalent C arithmetic and from
that point it is doubtful that the Allegro compiler will do better than the
optimizing C-compiler.
I would like to add an Amen to Jim McDonald's points about benchmarking
and interpretation of benchmarks. [I saw an ad recently touting one lisp
as running "23% faster" than another on the Gabriels (except it didn't call
them that) without any explanation of how the benchmarks were made and
how they summarized the results.] Advertized benchmarks are typically
run on stand alone maxed out hardware. On real systems the small size
of the C based Lisps (the total image size is about 2 megs
including compiler) is likely to be just as important as how registers
get used.
Another area where "C-based" lisps win is in the ability to tightly integrate
with "foreign" code. IBCL and KCL use the systems object format and their
Lisp data structures are also C data structures. The term "foreign" in this
case is essentially a misnomer.
Another issue that benchmarking doesn't account for is the lead time
between the availability of hardware and the availability of a Lisp.
For the six months or so when IBCL was the only lisp available
on the Sun 4 it might have been reasonable to compare IBCL on a Sun 4
with other Lisps on a Sun 3. This is the current situation on HP
Spectrum series and the MIPS based platforms (e.g., the Silicon Graphics
4D). This will undoubtedly be the situation for the new Apollo and
Motorola based RISCs in the future. In each case the companies
producing direct implementations are going to be in the business of
trying to duplicate all of the back end complexity of the manufacturer's
compilers. With the new architectures the complexity entailed in doing
decent instruction scheduling and register allocation and exploiting
low level parallelism is enormous. I doubt that this duplication
of effort will prove to be cost effective for most applications.
Dave Posner
IBUKI
ibuki!dbp@labrea.stanford.edu
------- End undelivered message -------
∂02-Dec-88 0919 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:18:27 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA13868; Fri, 2 Dec 88 09:17:02 PST
Message-Id: <8812021717.AA13868@trout.nosc.mil>
Date: 2 Dec 88 09:04:53 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Fri Dec 2 09:07:43 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA13709; Fri, 2 Dec 88 09:07:36 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:41 PST
Received: from fafnir.think.com by Think.COM; Fri, 2 Dec 88 11:13:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 2 Dec 88 11:34:51 EST
Received: by verdi.think.com; Fri, 2 Dec 88 11:33:22 EST
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812021633.AA05964@verdi.think.com>
To: jwz@spice.cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Jamie.Zawinski's message of Fri, 2 Dec 1988 00:40-EST <8812020545.AA12869@Think.COM>
Subject: commonlisp types
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Consider
(defun bazola (linguini pop-tarts)
(declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
...)
I'm trying to say that pop-tarts is always smaller in value than linguini.
The lambda expression appears lexically within the binding of linguini,
so one might expect that the free reference to linguini is legitimate.
But it can't work.
Similarly this cannot work:
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
...)
[Of course, this can be rendered instead as
(defun bazola (linguini pop-tarts)
(assert (< pop-tarts linguini))
...)
but that is beside the point.]
One might conceivably argue that SATISFIES should allow an actual
function and not just a name; then one might try
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
...)
but this approach doesn't help the declaration case. It's a basic problem
of compile-time versus run-time execution.
--Guy
∂02-Dec-88 0918 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:17:31 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA13816; Fri, 2 Dec 88 09:16:05 PST
Message-Id: <8812021716.AA13816@trout.nosc.mil>
Date: 2 Dec 88 09:03:53 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Thu Dec 1 18:23:53 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA27379; Thu, 1 Dec 88 18:23:33 PST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:06:41 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 1 Dec 88 10:48:06 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 1 Dec 88 11:04:43 EST
Date: Thu, 1 Dec 88 11:04 EST
From: Barry Margolin <barmar@Think.COM>
Subject: commonlisp types
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8812010255.AA17146@vaxa.isi.edu>
Message-Id: <19881201160446.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 30 Nov 88 18:55:38 PST
From: Don Cohen <donc@vaxa.isi.edu>
There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
The description of TypeP says that the type argument may be
any of the legal type specifiers except (function ...) or
(values ...).
I would hope that would mean that for any such "legal
arguments" typep would not cause an error. I would also
hope that any illegal type would cause an error.
On the other hand the description of how typep handles
(satisfies ...) indicates that errors might well result.
Intuitively, it seems to me that if an error results from
that test the typep test ought to return nil, e.g.,
(typep nil '(satisfies zerop))
I'd like the spec to say that typep first decides whether
the type is legal, and signals an error if not. Then,
for things like satisfies, it applies the predicate but
catches errors, and returns nil if an error occurs.
What do you experts (and lawyers) out there think?
Since CLtL doesn't say that TYPEP must signal an error if the type
specifier is invalid, it currently "is an error" if the type specifier
is not a valid type specifer other than (FUNCTION ...) or (VALUES ...).
I don't think there has been any suggestion within X3J13 to change this.
In general, Common Lisp tends not to require implementations to do lots
of this kind of checking; at high safety optimization levels it is
informally encouraged, but not required.
Actually, in this particular case, I don't think that requiring an error
to be signalled would be too bad. TYPEP must already do a significant
amount of work to decode the type specifier, so it probably knows when
the type specifier is invalid, and signalling an error would be pretty
easy. However, putting this requirement into the CL standard would be
an incompatible change to the language definition, with only minor gain,
and I think it is kind of late for it now (we're not very far from
trying to get a draft finished).
As for your suggestion about (SATISFIES ...), I personally think that is
a bad idea. TYPEP shouldn't silently hide bugs in the programmer's
predicate. The above example should have been written as
(typep nil '(and number (satisfies zerop)))
barmar
∂02-Dec-88 0918 ncr-sd!ncr-sd.SanDiego.NCR.COM!Postmaster@nosc.mil Returned mail
Received: from trout.nosc.mil by SAIL.Stanford.EDU with TCP; 2 Dec 88 09:17:41 PST
Received: by trout.nosc.mil (5.59/1.27)
id AA13833; Fri, 2 Dec 88 09:16:20 PST
Message-Id: <8812021716.AA13833@trout.nosc.mil>
Date: 2 Dec 88 09:04:15 PST
From: Postmaster@ncr-sd.SanDiego.NCR.COM
Subject: Returned mail
To: nosc!SAIL.Stanford.EDU!Common-Lisp-mailer@nosc.mil
Your mail could not be delivered because of the following reason:
hostname 'sauron' is unknown
----- Transcript of session follows -----
Executing: /usr/bin/uux - -gI -r sauron!rmail (lisa)
bad system name: sauron
uux failed ( 11 )
server "/usr/bin/uux" failed - host name unknown to UUCP
hostname 'sauron' is unknown
----- Unsent message follows -----
From SAIL.Stanford.EDU!Common-Lisp-mailer Thu Dec 1 22:37:45 1988 remote from nosc
Received: from SAIL.STANFORD.EDU by trout.nosc.mil (5.59/1.27)
id AA02483; Thu, 1 Dec 88 22:37:40 PST
Message-Id: <8812020637.AA02483@trout.nosc.mil>
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:04:56 PST
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
...but I believe it is the case that there is no CL way to determine
if a given type is defined.
I wish there was some CL way to define a complex type and insert it in
the existing hierarchy. For example, I once tried to define the type
LIST-OF, which would be used like
(TYPEP '(1 2 3) '(LIST-OF FIXNUM)) ==> T
(TYPEP '(A B 3) '(LIST-OF FIXNUM)) ==> NIL
(SUBTYPEP '(LIST-OF SYMBOL) 'LIST) ==> T
(SUBTYPEP '(LIST-OF FIXNUM) '(LIST-OF NUMBER)) ==> T
(SUBTYPEP '(LIST-OF *) '(LIST-OF LIST)) ==> NIL NIL
On the TI Explorer this was really easy.
In Lucid CL, it was not possible except by bashing the definitions of
TYPEP and SUBTYPEP.
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Jamie
∂02-Dec-88 0836 Mailer failed mail returned
To: Common-Lisp-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
GSB@ALDERAAN.SCRC.Symbolics.COM; yang%softy.DEC@decwrl.ARPA; common-lisp@gmdzi.uucp@UUNET.UU.NET; raible@AMES-NAS.ARPA
Here is how the remote host(s) replied to these mail addresses:
toad@NL.CS.CMU.EDU
450 Internal error forking to deliver mail
common-lisp@gmdzi.uucp@UUNET.UU.NET
550 <"common-lisp@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
------- Begin undelivered message: -------
02-Dec-88 0836 Common-Lisp-mailer commonlisp types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:41 PST
Received: from fafnir.think.com by Think.COM; Fri, 2 Dec 88 11:13:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 2 Dec 88 11:34:51 EST
Received: by verdi.think.com; Fri, 2 Dec 88 11:33:22 EST
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812021633.AA05964@verdi.think.com>
To: jwz@spice.cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Jamie.Zawinski's message of Fri, 2 Dec 1988 00:40-EST <8812020545.AA12869@Think.COM>
Subject: commonlisp types
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Consider
(defun bazola (linguini pop-tarts)
(declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
...)
I'm trying to say that pop-tarts is always smaller in value than linguini.
The lambda expression appears lexically within the binding of linguini,
so one might expect that the free reference to linguini is legitimate.
But it can't work.
Similarly this cannot work:
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
...)
[Of course, this can be rendered instead as
(defun bazola (linguini pop-tarts)
(assert (< pop-tarts linguini))
...)
but that is beside the point.]
One might conceivably argue that SATISFIES should allow an actual
function and not just a name; then one might try
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
...)
but this approach doesn't help the declaration case. It's a basic problem
of compile-time versus run-time execution.
--Guy
------- End undelivered message -------
∂02-Dec-88 1009 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1035 Common-Lisp-mailer Re: inconsistency in backquote spec?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST
Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 29 Nov 88 10:23:29 PST (Tuesday)
Subject: Re: inconsistency in backquote spec?
From: "Larry_Masinter.PARC"@Xerox.COM
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.EDU
In-Reply-to: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28
Nov 88 18:12
Message-ID: <881129-102742-5383@Xerox>
There are two relevant cleanup proposals, one of which passed, and the
other still pending. The first, called APPEND-DOTTED, clarifies the
behavior of APPEND given dotted lists. The second, which is really not firm
at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify
more precisely the behavior of backquote in terms of what parts of the
expansion get newly consed, etc.
Status: PASSED
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list. The only case
explicitly mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any
LISP object, which becomes the tail end of the constructed list. For
example, (append '(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list
to be returned.
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17)
=> 17, where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted
list. Xerox Common Lisp signals an error on APPEND and implements the
proposed interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those
implementations which don't already implement it. However, implementations
which have microcoded APPEND or NCONC incompatibly may find the small
change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect
only NIL when SAFETY is 0. In this case, depending on implementation
details, requiring an ATOM check rather than a NULL check may slow things
down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC
can therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND and NCONC can reliably deal in general with dotted
lists, something that doesn't appear to be guaranteed by a strict reading.
The proposed extension would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between lists
and dotted lists. Those who view dotted lists as a special kind of list may
feel differently than those who view lists as a special kind of dotted
list.
Discussion:
The cleanup committee supports this proposal.
------- End undelivered message -------
∂02-Dec-88 1010 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1050 Common-Lisp-mailer inconsistency in backquote spec?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST
Date: Tue, 29 Nov 88 13:55 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: jonl@lucid.com, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811290810.AA00624@bhopal>
Message-ID: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 00:10:53 PST
From: Jon L White <jonl@lucid.com>
re: However, the example at the bottom of page 350 suggest alternate
"legitimate interpretations" continued on the top of pg 351. All of
them except the first, consider (APPEND .... D NIL) to be equivalent to
(APPEND ... D), which isn't true if D can be a dotted list.
[This may be a question about "standard lists" more than about backquote.]
I remember some sleeping dogs about APPEND -- all arguments except the last
are required to be "lists". Since APPEND has to copy the next to last
argument, it must cdr down to the last cell of the list; thus it should
complain about non-standard lists. [The permission to use non-standard
lists is primarily when the operation of interest will not cdr down to
the last cell, and hence it would be a moot question.]
Long long ago, Lucid made the decision to make non-standard lists acceptable
just about everwhere that "lists" are. Thus in Lucid Common Lisp:
(APPEND '(A . B) NIL) ==> (A)
(APPEND NIL '(A . B)) ==> (A . B)
I agree with this (I think there's a CL cleanup that specifies this
behavior for APPEND and NCONC), and therefore the Lucid backquote
implementation is inconsistent with the definition of APPEND.
(setq d '(a . b))
`(,@d)
`(,@d . nil)
(append [,@d] 'nil)
(append d 'nil)
(append '(a . b) 'nil)
should be (a), as in your example above.
However, it was (a . b) on the version I tried - I didn't try the APPEND
case itself, so maybe in a later version both were made consistent.
I can't say that I am fully happy with this; but it's very low on my
list of worries today.
-- JonL --
------- End undelivered message -------
∂02-Dec-88 1010 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1127 Common-Lisp-mailer Re: Common Lisp for SUNS
Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST
Received: by tut.cis.ohio-state.edu (5.59/2.881128)
id AA25824; Tue, 29 Nov 88 14:12:36 EST
Date: Tue, 29 Nov 88 14:12:36 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu>
To: barmar@think.com
Cc: common-lisp@sail.stanford.edu
Subject: Re: Common Lisp for SUNS
>
>Kyoto CL is not generally considered a high-performance Lisp. Its major
>feature is its portability, since it is written mostly in C and its
>compiler uses C as the intermediate language. It is also well-known for
>being very faithful to CLtL, implementing all and only what the book
>says.
We're in the process of coming up with a decision on what lisp to get
for the University, and have been looking at Ibuki, Franz, and Envos
(and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has
been benchmarking them on Sun-3's and Sun-4's, and we've noticed that
in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind
of amazed by this, until we realised that Ibuki uses the native C
compiler, which is optimising for the SPARC architecture on the -4,
while none of the others were. This wasn't an across-the-board
speedup, just for some of the things we tried. I'd pretty much agree
with your other assessment of Kyoto CL, modulo the fact that Ibuki has
extended it somewhat (folding in the new error system, for example).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
------- End undelivered message -------
∂02-Dec-88 1010 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1138 Common-Lisp-mailer inconsistency in backquote spec?
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
To: gls@Think.COM, Greenwald@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8811291735.AA00711@joplin.think.com>
Message-ID: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
Date: Mon, 28 Nov 88 20:44 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
(setq d '(a . b))
'`(,@d) => `(a . b) or `(a)?
If you read CLtL, pg 350. it says that it's equivalent to
`(,@d . nil)
which is
(append [,@d] 'nil)
(append d 'nil)
which suggests the correct value is `(a).
...
Are dotted lists not allowed as values of D? Is the spec on pg 350
correct, and the examples on pg. 351 incorrect?
I tend to believe the latter. In which case, all of the readers I tried
are incorrect. I'm not going to change the Genera reader, though, until
I hear from this list, in case my brain is just wedged. Can someone
either deconfuse or support me?
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Or, you could say that the list following a ,@ cannot be dotted.
Either way, I think, requires a minor clarification in the CL spec.
The examples on page 351 are also correct. Once you are given that
D may not be dotted, and given that the result of a backquoted
expression may or may not make copies, then the examples shown are
correct optimizations.
--Guy
------- End undelivered message -------
∂02-Dec-88 1014 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1014 CL-Cleanup-mailer Re: Issue: TAILP-NIL (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 10:13:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 88 09:44:06 PST
Date: 2 Dec 88 09:43 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAILP-NIL (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 2 Dec 88 04:16 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: SEB1525@draper.com, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881202-094406-1195@Xerox>
This gives me a reason for wanting to disallow non-lists as the first
argument to TAILP -- that it would have to use EQL to be consistent.
------- End undelivered message -------
∂02-Dec-88 1020 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1020 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 10:13:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 88 09:46:10 PST
Date: 2 Dec 88 09:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 2 Dec 88 05:35 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: gsb@ALDERAAN.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881202-094610-1204@Xerox>
The proposal to add OPEN-STREAM-P is part of another issue, STREAM-ACCESS.
------- End undelivered message -------
∂02-Dec-88 1214 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1214 CL-Cleanup-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 12:14:31 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 88 11:59:38 PST
Date: 2 Dec 88 11:57 PST
From: masinter.pa@Xerox.COM
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
To: cl-cleanup@SAIL.Stanford.EDU
cc: cutting.pa@Xerox.COM
Message-ID: <881202-115938-1581@Xerox>
I took KMP's wording and used it in the Proposal.
!
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Version 2 by Masinter 2-Dec-88
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW):
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not specified.
In particular, the results of calling UNREAD-CHAR after PEEK-CHAR
is unspecified.
Example:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
This is not legal, since the PEEK-CHAR for char2a "commits"
the character read by char1a, and so the unread-char is not legal.
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another did not.
In Symbolics Genera, for the Example above:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
Cost to Implementors:
Presumably none. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
----- End Forwarded Messages -----
------- End undelivered message -------
∂02-Dec-88 1233 Mailer@MCC.COM Message of 30-Nov-88 14:17:39
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 12:33:32 PST
Date: Fri 2 Dec 88 14:25:49-CST
From: The Mailer Daemon <Mailer@MCC.COM>
To: CL-Object-Oriented-Programming-mailer@SAIL.STANFORD.EDU
Subject: Message of 30-Nov-88 14:17:39
Message undelivered after 2 days -- will try for another 1 day:
CL-Object-Oriented-Programming@Hal.CAD.MCC.com: Cannot connect to host
------------
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 30 Nov 88 14:17:42-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu
-------
∂02-Dec-88 1238 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1353 Common-Lisp-mailer Re: Common Lisp for SUNS
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST
Received: by ucbarpa.Berkeley.EDU (5.61/1.29)
id AA24518; Tue, 29 Nov 88 13:52:04 PST
Received: from frisky by franz (3.2/3.14)
id AA24713; Tue, 29 Nov 88 13:43:03 PST
Received: by frisky (3.2/3.14)
id AA02600; Tue, 29 Nov 88 13:40:54 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8811292140.AA02600@frisky>
To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase)
Cc: franz!sail.stanford.edu!common-lisp
Subject: Re: Common Lisp for SUNS
In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST.
<8811291614.AA01479@red.ipsa.dnd.ca>
Date: Tue, 29 Nov 88 13:40:53 PST
Regarding benchmarking Lisps.
1. Declarations are important for speed, but you'll find that some
Lisps will require more specific declarations than others.
For example Sun's Lisp only supports one floating point type so declaring
something to be a 'float' is sufficient for the compiler to open code
the operation. Allegro supports two types of floats so you must declare
either 'single-float' or 'double-float.'
2. Different systems do different amounts of optimizations based on
the settings of the optimization parameters speed, safety and size.
Probably the only comparable values are for speed=3, safety=0, size=0
where each system does maximum optimization. While benchmarks
run at this value are interesting you probably aren't going to
do development with these settings since you aren't going to get
good diagnostics.
Regarding the Lisp on the Sun4.
Allegro is highly optimized for the Sun4 but you have to
add some declarations and specify that speed is important.
The comment was made that a C based Lisp on the Sun4 would
be very fast because of sun's optimizing C compiler.
While it is true that by using C you can take advantage of that
compiler, it is also true that the use of C constrains your
whole system design so you can't use the machine optimally.
I say this from many years experience programming in C parts of the
kernel of Franz Lisp. To cite two examples for the Sun4:
One of the nicest features of the sun4 (sparc) architecture
is the support the the Lisp fixnum data type (there are 'tagged'
versions of the add, subtract and compare instructions).
This allows the compiler to open code +,-,<,<=.. and so on
and if the operands happen to be fixnums (they very often are)
then the operation and fixnum tag check can go on in parallel.
This makes for fast computation in the typical case
and it is completely safe (if the tags aren't fixnum you find out
about it and perform the appropriate operation for the
actual data types).
A C based lisp can't make use of these tagged instructions.
The Sun4 has 7 global registers. Allegro stores nil and a
pointer to our global function table in one of them, and
uses another for tracking asychronous interrupts. Another
is used to pass argument/result counts. C doesn't permit
global register declarations so you can't take advantage
of this nice feature of the Sun4 in a C-based Lisp.
[The use of machine registers to hold certain values was
so important in Franz Lisp that for certain regular
architectures (e.g. vax) an incredible hack was written
by Keith Sklower to modify the assembler language coming
out of the C compiler to change certain memory references
to register references and to fix the register save masks.]
-- John Foderaro
Franz Inc.
jkf%franz.uucp@berkeley.edu
------- End undelivered message -------
∂02-Dec-88 1239 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 1430 Common-Lisp-mailer inconsistency in backquote spec?
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST
Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST
Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST
Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST
Date: Tue, 29 Nov 88 17:12:40 EST
From: gls@Think.COM
Message-Id: <8811292212.AA00825@joplin.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com,
common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: inconsistency in backquote spec?
Date: Tue, 29 Nov 88 14:05 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Tue, 29 Nov 88 12:35:36 EST
From: gls@Think.COM
...
You raise some good points here. At first I was certain that the book
was not consistent, but now I have the following language lawyer's
argument:
The spec for APPEND says that all arguments but the last must be lists.
The comment about the last argument makes it clear that the others
are meant to be proper lists; see also the middle paragraph of page 27.
Therefore dotted lists are not allowed as values for D.
I thought a (recent?) CL Cleanup specified that if arguments (all but
the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR
was to be ignored. In which case, the examples on 351 are incorrect.
Because you sent the mail out to common-lisp@sail and not to
any of the X3J13 mailing lists, I assumed that you were asking
a question about the language as defined solely by the book.
In other words, I assume that the audience for the common-lisp
mailing list has not necessarily followed all of the X3J13 work.
It is true that eventual adoption of this cleanup item would
invalidate the examples.
--Guy
------- End undelivered message -------
∂02-Dec-88 1150 Mailer failed mail returned
To: CL-Windows-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
puccio@MEDIA-LAB.MEDIA.MIT.EDU; hultquis@prandtl.nas.nasa.gov; lispx-gmd@gmdzi.uucp@UUNET.UU.NET; eric@SCUBED.ARPA; York@Chuck-Jones.ILA-West.Dialnet.Symbolics.COM
Here is how the remote host(s) replied to these mail addresses:
puccio@MEDIA-LAB.MEDIA.MIT.EDU
550 <puccio@MEDIA-LAB.MEDIA.MIT.EDU>... User unknown
lispx-gmd@gmdzi.uucp@UUNET.UU.NET
550 <"lispx-gmd@gmdzi.uucp"@UUNET.UU.NET>... User unknown: Inappropriate ioctl for device
tk%moss@ATT.ARPA
421 research.att.com too busy, please try later
blewett%research.att.com%siriusb@RESEARCH.ATT.COM
421 research.att.com too busy, please try later
------- Begin undelivered message: -------
02-Dec-88 1150 CL-Windows-mailer Other-LISP-versions-of-CLUE
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 11:50:01 PST
Date: Fri, 2 Dec 88 14:58:33 EST
From: Ian Horswill <IDH@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
To: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU
cc: "CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-reply-to: Msg of Fri 2 Dec 88 08:59:36 +0200 from Jussi Opas <jho%hutcs.hut.fi at Forsythe.Stanford.EDU>
Message-ID: <497237.881202.IDH@AI.AI.MIT.EDU>
I got an old version running on lucid 3.0. It worked fairly well, but
I haven't tried it for several months.
-ian
------- End undelivered message -------
∂02-Dec-88 1245 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1245 CL-Cleanup-mailer Re: Issue: TAILP-NIL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Dec 88 12:45:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 502067; Fri 2-Dec-88 15:44:22 EST
Date: Fri, 2 Dec 88 15:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAILP-NIL (Version 4)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, SEB1525@draper.com,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881202-094406-1195@Xerox>
Message-ID: <881202154353.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 2 Dec 88 09:43 PST
From: masinter.pa@Xerox.COM
This gives me a reason for wanting to disallow non-lists as the first
argument to TAILP -- that it would have to use EQL to be consistent.
Having had a night to think about it, I don't think the need to
use EQL is much of an argument against.
If the implementation does not inline TAILP, then TAILP can
select one of two trivial loops based on its argument type.
No significant slowdown there.
If the implementation does inline TAILP, then it can just put
in EQL and leave it to optimizers for variable declarations
and/or THE to notice that things declared to be LIST (or at
least (AND (NOT NUMBER) (NOT CHARACTER)) can be optimized).
We use effectively the same argument to justify making EQL the
proper test for MEMBER in spite of the superficial impression of
non-efficiency, so I'll be interested to hear anyone try to refute
this position.
As to the use of ENDP, I think the overriding argument has to be
that ENDP is appropriate only for list abstractions, and I absolutely
don't see this as a useful list abstraction. [Explanation below.]
As to the use of EQL, I think there is no justification for using
EQ in the language anywhere, other than providing the function itself
and providing the facility of other functions to take [#]'EQ as an
argument, and even that is fairly questionable in portable code.
The reason I don't think TAILP is an operation on lists is that all
the list abstractions go to a lot of trouble to say that cars and
cdrs can be changed willy-nilly. If you do much of anything to a list,
you have to be afraid that EQ-ness of something in the container
has been destroyed. The only thing all the list operations tend to
preserve is overall shape. Hence, it's dumb to have an operation
which claims to be about lists and yet which uses a type predicate
which is seriously inappropriate to lists. If TAILP were really
about lists, it would want to use something like EQUAL as a predicate.
I think TAILP is most useful when you've gone to some care to construct
a cdr-chain from scratch using only cons and custom maintenance
primitives. In any case where custom primitives are involved, any
expectation that ever cdr-chain is going to be a proper list is out
the window. If you restrict TAILP to work only on proper lists, you
place an arbitrary restriction on it which makes it not useful in
a number of places where it might otherwise be useful.
I think the reason we don't have anyone arguing passionately about
what TAILP should do from experience is that it is seldom useful in
practice.
I think the reason it is seldom useful is that it is not defined on the
full set of data types that it needs to be defined on.
My now-considered position is that I am firm in the idea that the end
test should be ATOM and that the test should be EQL.
------- End undelivered message -------
∂02-Dec-88 1254 mad!uucp@labrea.stanford.edu
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 12:54:20 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 12:53:09 PST
Date: Fri, 2 Dec 88 12:53:09 PST
From: mad!uucp@labrea.stanford.edu
Message-Id: <8812022053.AA22017@labrea.stanford.edu>
Apparently-To: CL-Windows-mailer@SAIL.Stanford.EDU
remote execution [uucp job labreaCLGN3 (12/2-12:43:44)]
rmail mlj
exited with status 2
===== stderr was =====
Can't send to mlj
∂02-Dec-88 1254 mad!uucp@labrea.stanford.edu
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 12:54:34 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 12:53:23 PST
Date: Fri, 2 Dec 88 12:53:23 PST
From: mad!uucp@labrea.stanford.edu
Message-Id: <8812022053.AA22028@labrea.stanford.edu>
Apparently-To: CL-Windows-mailer@SAIL.Stanford.EDU
remote execution [uucp job labreaCLGR3 (12/2-12:43:50)]
rmail mlj
exited with status 2
===== stderr was =====
Can't send to mlj
∂02-Dec-88 1254 mad!uucp@labrea.stanford.edu
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 12:54:47 PST
Received: by labrea.stanford.edu; Fri, 2 Dec 88 12:53:36 PST
Date: Fri, 2 Dec 88 12:53:36 PST
From: mad!uucp@labrea.stanford.edu
Message-Id: <8812022053.AA22033@labrea.stanford.edu>
Apparently-To: CL-Windows-mailer@SAIL.Stanford.EDU
remote execution [uucp job labreaCLHV3 (12/2-12:43:55)]
rmail mlj
exited with status 2
===== stderr was =====
Can't send to mlj
∂02-Dec-88 1359 Mailer failed mail returned
To: CL-Compiler-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
Bartley@TI-CSL; hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1359 CL-Compiler-mailer Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 13:59:15 PST
Date: Fri 2 Dec 88 13:56:25-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
To: sandra%defun@CS.UTAH.EDU
cc: cl-compiler@SAIL.STANFORD.EDU, IIM@ECLA.USC.EDU
In-Reply-To: <8812020441.AA14009@defun.utah.edu>
Message-ID: <12451293213.32.IIM@ECLA.USC.EDU>
> From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Thu, 1 Dec 88 21:41:27 MST
> Subject: Re: Issues EVAL-WHEN-NON-TOP-LEVEL & DEFINING-FORMS-NON-TOP-LEVEL
>
> That may be your interpretation of what CLtL says, but it doesn't
> really say that explicitly.
I base my claim that Common Lisp already allows defining forms to
appear in non-top-level places on the following:
1. CLtL, Section 5.3, paragraph 2, page 66, says
"It is not illegal to use these forms at other than top level, but
whether it is meaningful to do so depends on context. Compilers,
for example, may not recognize these forms properly in other than
top-level contexts."
2. All of the defining forms are macros, so there must be a
corresponding macro definition for them (CLtL, page 57).
3. A compiler must handle macro calls properly in all contexts
(minimally, by simply calling macroexpand or macroexpand-1), but
may bypass the macro definition if it has special knowledge of the
form (CLtL, page 57).
Given the above three statements, the only meaning I can ascribe to
"may not recognize" is that the compiler's special treatment of these
forms may not occur in other than top-level contexts. In fact, CLtL
page 57 uses the word "recognize" to mean having special knowledge of
the form. I contend that an implementation that doesn't allow such
forms in non-top-level contexts violates CLtL, and that what we should
be trying to do in DEFINING-FORMS-NON-TOP-LEVEL is specify what they
mean in such contexts, which I admit doesn't seem to be all that well
defined.
> As I understand it, the key to what you are proposing is making
> (EVAL-WHEN (COMPILE) ...) cause compile-time evaluation only if it
> appears at top-level.
Correct. Tightening up the definition of top-level also needs to be
done, but that should probably be a seperate issue. For example,
EVAL-WHEN should not affect it, though I don't know of anything that
specifically says that is the case.
kab
-------
------- End undelivered message -------
∂02-Dec-88 1405 MAILER-DAEMON@decwrl.dec.com Returned mail: Cannot send message for 3 days
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 14:05:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for X3J13-mailer@sail.stanford.edu; id AB19179; Fri, 2 Dec 88 14:04:45 PST
Date: Fri, 2 Dec 88 14:04:45 PST
From: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8812022204.AB19179@decwrl.dec.com>
To: <X3J13-mailer@sail.stanford.edu>
----- Transcript of session follows -----
mail11: connect to bach failed, Host is unreachable
----- Unsent message follows -----
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for bizet::mahoney; id AA17129; Tue, 29 Nov 88 13:13:12 PST
Message-Id: <1$Iq4z@SAIL.Stanford.EDU>
Date: 29 Nov 88 1235 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: ISO Meeting Report
To: x3j13@SAIL.Stanford.EDU
Fellow Colleagues:
The following is my report on the November ISO meeting. I am sending
this now for several reasons. First, because it is fresh in my mind.
Second, because the events are a little more dramatic than usual.
Third, because one outcome was the cancellation of the January ISO
meeting in Hawaii.
The US Delegation consisted of Bob Mathis, Thom Linden, Patrick
Dussud, Gregor Kiczales, and myself. The meeting was held at the
Building of the European Community in Brussels, Belgium. It was held
Monday and Tuesday, November 21 and 22.
Attending were France, The Netherlands, Germany, Japan, the UK, and
the US.
The US presented its position statement, which is as follows:
************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. The
near term standardization of ISO Common Lisp would have substantial
positive impact on the acceptance of existing commercial Lisp
implementations and on the viability of future Lisp dialects as
vehicles for emerging applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
************************************************************************
In addition, we proposed the following resolution:
************************************************************************
The U.S. proposes the following ISO WG16 resolution:
It is important to affirm and strengthen the position of the
international community of users who depend on Common Lisp. It is
also imperative that an international standard for Common Lisp must be
subject to international review and revision.
ISO WG16 resolves to proceed with an ISO Common Lisp standardization
process in the following manner:
* WG16 requests X3J13 to produce an ISO draft standard for Common
Lisp in accordance with SC22 synchronization principles for national
body development.
* The X3J13 drafting procedure will accommodate international public
review as well as U.S. public review. X3J13 will establish a schedule
to allow processing of all public comments.
* The timetable for forwarding a draft for circulation by WG16 is
December 1989. The U.S. should make every effort to meet this
schedule.
* X3J13 will inform WG16 of its schedules and progress.
************************************************************************
The German Delegation also had a written position statement. It is as
follows:
************************************************************************
The Position of DIN concerning LISP standardization
Herbert Stoyan
University of Konstanz
November 18, 1988
1. Our Goals
When the LISP-standardization process started we were optimistic to reach a
quick result. Now we have to change our feeling. It will take longer than we
have imagined. To speed up the process we want to change some of our position
statements made in Paris.
First, we voted for CommonLISP as a starting point for standardization. We
want to change this commitment into an open one. We join the US that one of
Scheme or CommonLISP (but not both) should be used.
Second, we made a vote for desirable characteristics of the standard. We
regret that not all points went as we desired. But the issues seem to be
mixed: There are language issues and report issues.
Before all the points, we should all agree that standardization is only
partially a language definition activity. We should standardize an existing
language. Therefore we don't like anymore the list of default values for
language components. If we still intend to follow this direction we get
everything but a language which is usable. We don't feel that this was a good
idea. DIN will accept any proposal for a LISP standard and check every part
of it - not only functional objects etc.
Obviously, the goal of standardization is portability. Therefore this issue
deserves most attention. We got here the right mark. The next issue of
standardization seems to be processor conformity. We would like to change our
figure `6' into a `2'. We believe the conformity must be provable: Without a
proof procedure for conformity our work is not complete. Especially, there
has to be a test suite.
The standard report must be technical clear. Therefore a clear semantics is
important. It is the way to achieve portability. We ranked this topic with
`3' and support this vote again. The standard report has to be
understandable. An important means to achieve this is a simple semantics. We
miss understandability as characteristics and again want to stress our figure
`4' here.
A standard report has to be usable. That means, it should be well organized,
it should not be too voluminous, it should be use not too many references to
other parts. Maybe this was meant by `Ease of learning'. We believe that
this characteristic is only an indicator for this quality of the standard.
Therefore we want to change our figure of `12' into a `5'.
Now, concerning the language. A language to be standardized must be
interesting. That must be already - we cannot change it. May be this is what
was meant as `Power'. We want to rank this point at first place in the
language goals we have. Power does not mean to provide everything. A
language which is too large and complex has no power and will not be
appealing. History of programming languages proves that baroque languages
will not last for long. Therefore we want to vote for `Compactness' - but it
is not in the list of characteristics.
If a language is big only because of many concepts which enable variations of
expressions for one and the same thing then the language is defined badly. If
the language contains elements which cannot be combined it should be regarded
as a family of languages. Both dimensions are called orthogonality. We want
to vote for `Orthogonality' - but cannot find it.
There are characteristics of implementations. Issues like efficiency,
consistency interpreter/compiler, stability etc. come in mind. They are goals
for implementors. Good implementors will achieve them - bad implementors wil
fail. These are not goals of standardization.
Ease of implementation is a goal which is always fulfilled with LISP. The art
is to find a way to quality.
2. The Situation
Our original proposal was to standardize a kernel of LISP with parts everybody
will accept readily. This work could be done in 18 month. But there are not
many countries to support this approach.
Richard Gabriel made the point that three languages should not be
standardized. We adopt this position. We have to ask who moved us in the
position where this danger is to be faced. Obviously, it is the pair of
US-activities. It was clear to ANSI that CommonLISP is not ready for
standardization. A de-facto standard ist not a true standard. We want not
decide without studying the latest draft of CommonLISP if it achieved enough
quality. Furthermore, we have the feeling that the activity for standardizing
Scheme was started to contravene the European desire for a clean LISP kernel.
3. Our Proposal
ISO is not an organisation for creating new languages. The maximal thing we
should plan is to change a presented language somewhat. The French have
exposed the three level approach. There seems nobody (with exception of DIN)
who likes the idea.
Therefore: We propose to take the draft reports of CommonLISP and Scheme
and check them for quality of being standardized. If they both have the
quality, we should standardize both of them with ISO. If only one has
the quality we should take this one. If none of the has the quality we
should generate a list of required changes and wait for better drafts. In the
meantime other member bodies are invited to define LISPs which deserve
standardization.
************************************************************************
In summary, they commented that the current ISO process does not seem
to be converging on a standard quickly enough, and that a short-term
standard can produced only by working with an existing dialect and
draft. They proposed that drafts for X3J13 Common Lisp and IEEE Scheme
be considered and measured against several criteria. These are that
the draft be clear and unambiguous, not unacceptably long (< 300 pages
was suggested), and precisely stated. The languages ought to be as
crisp and orthogonal as possible (that is, minimal redundant
features). The German Delegation proper consisted of Klaus Daessler
(Siemens), Dieter Kolb (Siemens), and Herbert Stoyan (University of
Konstanz). Kolb favors Common Lisp and the other two favor Scheme, but
the German position allowed for both to be selected and standardized
by ISO.
No other delegation had a written position statement. The Japanese
Delegation consisted of Professor Ito and Mr Kurokawa. Professor Ito
is primarily concerned about CLOS, but after private discussions I
learned that because of lack of study he did not understand it, and
the expert group that advises him consists of object-oriented
programming researchers who press their own ideas on him.
The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
They responded by remarking that the US position represented a
``preposterous'' change in position by the US and directly
contradicted the agreed-upon work item. This work item was the AFNOR
(French) position which was to standardize a Common-Lisp-like dialect
with no packages, simple lambda-lists, simple arrays, generic
functions without classes, a different multiple value system, and a
different syntax for specials. The US argued that this plan was never
voted on because the convener would not allow it: He exaplined that
because it was a technical proposal, it was subject to discussion as
are all other technical points.
The US further remarked that the US position allowed for multiple
standardized dialects, but the convener denied this was possible under
the current work item and suggested we could try introducing a second
work item.
The French delegation contended that the US plan was to block the ISO
process. They were right in the limited sense that I threatened to
block the standardization of any dialect of Common Lisp that was
neither a superset nor a subset of Common Lisp.
I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant. Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''
As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
be available in the first half of 1989 (Beta available in December).
He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting).
The convener declared that discussion on this topic was deadlocked
until AFNOR could meet to decide their response to the US and German
position statements, which would not be until after the Hawaii
meeting. However, the convener told Mathis in private that he did not
want to go to Hawaii and was trying to find a way to cancel the
meeting. The convener also threatened to report failure to SC22 based
on his opinion that a consensus is not possible.
The US delegation agreed to ask X3J13 and the IEEE Scheme groups
whether they were willing to submit drafts under the German proposal.
While so agreeing, we pointed out that the convener was acting as if
the German position would be accepted. I pointed out that the US had
not withdrawn its proposed resolution.
The US delegation repeatedly commented that the US position was
intended to support Common Lisp users and was not intended to prevent
other distinct standards from being established to serve other
communities.
I expect that the word from AFNOR to the European community will be
that the US deliberately tried to block the ISO process, though I'm
not sure what reason he will provide for the US actions.
The second day of the meeting was devoted to three presentations:
Gabriel presented a report on the progress that US Common Lisp vendors
had made in the area of delivery of applications written in Common
Lisp. Mr Kurokawa presented a report on Japanese activity on
provisions within Common Lisp for international character sets. Thom
Linden presented the latest X3J13 work on the same topic. In
addition, the U.S. was asked to present the current WG16 status on
character handling at the next SC22 meeting.
The next ISO meeting is in March in Fairfax, Virginia.
-rpg-
∂02-Dec-88 1359 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1359 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 13:58:57 PST
Date: Fri 2 Dec 88 13:54:11-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
To: KMP@SCRC-STONY-BROOK.ARPA
cc: Masinter.PA@XEROX.COM, CL-Cleanup@SAIL.STANFORD.EDU, IIM@ECLA.USC.EDU
In-Reply-To: <881202062445.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <12451292808.32.IIM@ECLA.USC.EDU>
Date: Fri, 2 Dec 88 06:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)
... in all cases where CLASS-OF is well-defined and would return a
class which has a proper name, then TYPE-OF should return that
proper name -- no?
Close, but I think the following is legitimate:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
(type-of *foo*) => (SIMPLE-VECTOR 5)
In other words, type-of should be permitted to return more information
than class-name on class-of.
kab
-------
------- End undelivered message -------
∂02-Dec-88 1502 Mail Delivery Problem
Received: from amrf (amrf.cme.nbs.gov) by SAIL.Stanford.EDU with TCP; 2 Dec 88 15:02:33 PST
Date: 2 Dec 88 17:41:28 EST
From: "SMTP MAILER" <postmaster@amrf>
Subject: Mail Delivery Problem
To: <cl-windows-mailer@sail.stanford.edu>
----Reason for mail failure follows----
Sending mail to recipient(s) meunier :
Couldn't make final delivery.
----Transcript of message follows----
Received: from SAIL.Stanford.EDU by amrf with SMTP ; Fri, 2 Dec 88 17:35:11 EST
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 11:50:01 PST
Date: Fri, 2 Dec 88 14:58:33 EST
From: Ian Horswill <IDH@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
To: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU
cc: "CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-reply-to: Msg of Fri 2 Dec 88 08:59:36 +0200 from Jussi Opas <jho%hutcs.hut.fi at Forsythe.Stanford.EDU>
Message-ID: <497237.881202.IDH@AI.AI.MIT.EDU>
I got an old version running on lucid 3.0. It worked fairly well, but
I haven't tried it for several months.
-ian
∂02-Dec-88 1519 Mailer@XX.LCS.MIT.EDU Message of 2-Dec-88 10:07:36
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 15:18:55 PST
Date: Fri 2 Dec 88 18:14:32-EST
From: The Mailer Daemon <Mailer@XX.LCS.MIT.EDU>
To: CL-Windows-mailer@SAIL.Stanford.EDU
Subject: Message of 2-Dec-88 10:07:36
Message failed for the following:
jloaiza%oracle@hplabs.hp.com: 554 <jloaiza%oracle@hplabs.hp.com>... Nameservice says unknown host or domain name
------------
Received: from ZERMATT.LCS.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Fri 2 Dec 88 10:07:38-EST
Received: from SAIL.Stanford.EDU (INTERNET|10.0.0.11) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 214953; 2 Dec 88 10:09:08 EST
Received: from forsythe.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:04:51 PST
Received: by Forsythe.Stanford.EDU; Fri, 2 Dec 88 07:04:42 PST
Received: from FINHUTC.HUT.FI by Finhutc.HUT.FI (Mailer R2.01) with BSMTP id
5441; Fri, 02 Dec 88 16:50:42 EET
Received: from santra.hut.fi by FINHUTC.HUT.FI ; 2 Dec 88 16:50:41 EET
Received: from hutcs.hut.fi by santra.hut.fi
(5.57/ida/6.8/TeKoLa) id AA28692; Fri, 2 Dec 88 08:56:57 +0200
Received: by hutcs.hut.fi (5.57/ida/6.6/S-TeKoLa)
id AA01081; Fri, 2 Dec 88 08:59:36 +0200
Date: Fri, 2 Dec 88 08:59:36 +0200
From: Jussi Opas <jho%hutcs.hut.fi@Forsythe.Stanford.EDU>
Message-Id: <8812020659.AA01081@hutcs.hut.fi>
To: cl-windows@sail.stanford.edu, clue-review@dsg.csc.ti.com
Subject: Other-LISP-versions-of-CLUE
Now, do somebody know, whether CLUE has been run
succesfully in other versions of LISP. Such as Lucid or KCL.
If yes, then who and where. If not, the why.
A fast response expected.
Jussi Opas
Helsinki University of technology
Laboratory of Information Processing Science
Otakaari 1 A
02150 Espoo 15
Finland
mail addresses: jho%hutcs.uucp@fingate.bitnet
uuco:mcvax!hutcs!jho
internet:jho@hutcs.hut.fi
-------
∂02-Dec-88 1519 Mailer@XX.LCS.MIT.EDU Message of 2-Dec-88 10:18:40
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 15:19:07 PST
Date: Fri 2 Dec 88 18:15:03-EST
From: The Mailer Daemon <Mailer@XX.LCS.MIT.EDU>
To: CL-Windows-mailer@SAIL.Stanford.EDU
Subject: Message of 2-Dec-88 10:18:40
Message failed for the following:
jloaiza%oracle@hplabs.hp.com: 554 <jloaiza%oracle@hplabs.hp.com>... Nameservice says unknown host or domain name
------------
Received: from ZERMATT.LCS.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Fri 2 Dec 88 10:18:42-EST
Received: from SAIL.Stanford.EDU (INTERNET|10.0.0.11) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 214955; 2 Dec 88 10:13:55 EST
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 2 Dec 88 07:08:56 PST
Date: 1 Dec 88 11:06:47 EST
From: Timothy Daly <DALY@ibm.com>
To: cl-windows@sail.stanford.edu
Message-Id: <120188.110651.daly@ibm.com>
Subject: streams to common lisp windows.
Well, I HAVE succeeded in implementing a function that will return
the READ of a window. It is truly ugly but it works. The essential
steps are:
catch :exit
event-case to capture keycodes (NOT ascii)
when :key-press
convert key to ascii
when key is of type character
concat to buffer
if key is a constituent char
then exit event-case
else continue event-case
event-case to throw away the key event (discard-p t)
condition-case (with-input-from-string (s buffer) (setq result (read s)))
on simple-condition-error (setq result :fail)
unless (eq result :fail) (throw :exit result)
essentially, i capture each key-press event, convert it to ascii,
and if it is an ascii character I add it to the buffer. The constituent
character check is there to wait until there is some terminating input
character before calling READ (else 376 is returned as 3 (read succeeds
early)).
next, i have to throw away the key-press event from the event queue
since it was requeued by exiting the first event-case
then, i use the condition system to keep READ safe from errors and
attempt a READ on the buffer. If READ succeeds (it might be reading
a partial list and fail) then I return the result, else I continue.
I understand that this is incredibly clanky but X-Windows wants me
to write my program as an EVENT-CASE structure and other window
systems will allow READs to windows. My code is designed to port
to other window systems.
One (flame-like) comment: X-Windows is designed as a policy-free
window system but it strongly constrains the designs of programs
that use it. Methinks this might need discussion.
Tim
DALY@IBM.COM
IBM T.J.Watson Research Center
Yorktown Heights, N.Y. 10598
-------
∂02-Dec-88 1520 cvbnet!MAILER-DAEMON@decvax.dec.com Returned mail: Unable to deliver mail
Received: from decvax.dec.com by SAIL.Stanford.EDU with TCP; 2 Dec 88 15:19:53 PST
Received: by decvax.dec.com (5.57/v2.4)
id AA17482; Fri, 2 Dec 88 18:19:22 EST
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AC15923; Fri, 2 Dec 88 18:01:10 EST
Date: Fri, 2 Dec 88 18:01:10 EST
From: cvbnet!MAILER-DAEMON@decvax.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8812022301.AC15923@cvbnet.prime.com>
To: CL-Windows-mailer@SAIL.Stanford.EDU
----- Transcript of session follows -----
554 basie!tbardasz... No known UUCP connection to basie
554 decvax!SAIL.Stanford.EDU!CL-Windows-mailer... Possible alias loop
554 No valid recipients
----- Unsent message follows -----
Return-Path: <SAIL.Stanford.EDU!CL-Windows-mailer@decvax.uucp>
Received: by cvbnet.prime.com (3.2/SMI-3.2)
id AA15923; Fri, 2 Dec 88 18:01:10 EST
Received: from Sail.Stanford.EDU by decwrl.dec.com (5.54.5/4.7.34)
for decvax!cvbnet!basie!tbardasz; id AA12811; Fri, 2 Dec 88 12:12:07 PST
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 11:50:01 PST
Date: Fri, 2 Dec 88 14:58:33 EST
From: Ian Horswill <AI.AI.MIT.EDU!IDH@decvax.uucp>
Subject: Other-LISP-versions-of-CLUE
To: FORSYTHE.STANFORD.EDU!jho@hutcs.hut.fi
Cc: "CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: Msg of Fri 2 Dec 88 08:59:36 +0200 from Jussi Opas <jho%hutcs.hut.fi at Forsythe.Stanford.EDU>
Message-Id: <497237.881202.IDH@AI.AI.MIT.EDU>
I got an old version running on lucid 3.0. It worked fairly well, but
I haven't tried it for several months.
-ian
∂02-Dec-88 1523 Mailer@XX.LCS.MIT.EDU Message of 2-Dec-88 14:56:46
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 15:23:41 PST
Date: Fri 2 Dec 88 18:19:07-EST
From: The Mailer Daemon <Mailer@XX.LCS.MIT.EDU>
To: CL-Windows-mailer@SAIL.STANFORD.EDU
Subject: Message of 2-Dec-88 14:56:46
Message failed for the following:
jloaiza%oracle@hplabs.hp.com: 554 <jloaiza%oracle@hplabs.hp.com>... Nameservice says unknown host or domain name
------------
Received: from ZERMATT.LCS.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Fri 2 Dec 88 14:56:48-EST
Received: from SAIL.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 215059; 2 Dec 88 14:58:23 EST
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 11:50:01 PST
Date: Fri, 2 Dec 88 14:58:33 EST
From: Ian Horswill <IDH@AI.AI.MIT.EDU>
Subject: Other-LISP-versions-of-CLUE
To: jho%hutcs.hut.fi@FORSYTHE.STANFORD.EDU
cc: "CLUE-REVIEW@DSG.CSC.TI.COM"@AI.AI.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
In-reply-to: Msg of Fri 2 Dec 88 08:59:36 +0200 from Jussi Opas <jho%hutcs.hut.fi at Forsythe.Stanford.EDU>
Message-ID: <497237.881202.IDH@AI.AI.MIT.EDU>
I got an old version running on lucid 3.0. It worked fairly well, but
I haven't tried it for several months.
-ian
-------
∂02-Dec-88 1920 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1920 CL-Cleanup-mailer Status on cleanup items
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 19:20:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 88 16:30:34 PST
Date: 2 Dec 88 16:29 PST
From: masinter.pa@Xerox.COM
Subject: Status on cleanup items
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <881202-163034-129@Xerox>
I've finished what has been a month-long traversal alphabetically over the
open cleanup items. I plan next week to put together a ballot and hardcopy
of all of the ones that are ready for release. There are approximately 100
issues, a few of which have more than one proposal associated with them;
I'd guess that 20 of them are not ready for voting.
------- End undelivered message -------
∂02-Dec-88 1920 Mailer failed mail returned
To: CL-Cleanup-mailer@SAIL.Stanford.EDU
The following message was undeliverable to recipient(s):
hadden@hi-multics
------- Begin undelivered message: -------
02-Dec-88 1920 CL-Cleanup-mailer Re: Issue ALIST-NIL
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 19:20:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 88 16:38:52 PST
Date: 2 Dec 88 16:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue ALIST-NIL
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Thu, 1 Dec 88
13:48:59 PST
To: cl-cleanup@SAIL.STANFORD.EDU, Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <881202-163852-131@Xerox>
My belief at this time is that there are no longer any proponents for the
Proposal in this outline; the "Problem" can be accomodated by an editorial
change in the writeup of the standard rather than an actual change in the
language.
Unless I hear otherwise (and I'll leave this open for Kent, who is on
vacation until December 10 and may not read this until much later), I will
mark this as Withdrawn.
------- End undelivered message -------
∂02-Dec-88 2017 Mailer failed mail returned
To: Common-Lisp-mailer
The following message has expired without successful delivery to recipient(s):
silbert@NADC.ARPA
------- Begin undelivered message: -------
29-Nov-88 2057 Common-Lisp-mailer Common Lisp for SUNS
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST
Date: Tue, 29 Nov 88 23:42 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Common Lisp for SUNS
To: Bill Pase <bill@red.ipsa.dnd.ca>, common-lisp@sail.stanford.edu
In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca>
Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 29 Nov 88 11:14:29 EST
From: bill@red.ipsa.dnd.ca (Bill Pase)
I'm especially interested in the run time performance, since we hope
to use one of these lisps as a delivery vehicle for code developed on
Symbolics Computers. (It'd be real nice if the lisp benchmark data
was available?) Of course if anyone has experiences with using these
systems as a development environment, I'd not mind hearing it.
/bill
I have only subjective things to give you, but you will be astonished at the
performance difference between KCL and any Symbolics machine. I've only done
close-in comparisons with a Symbolics system with minimum memory, running on a
large Sun-3. For realistic size problems (like compilation, for instance),
KCL is pretty slow. Well, compilation isn't really a fair choice since it has
to get compiled twice; once in Lisp and once in C.
It is also pretty weak in the development arena. I would choose either of the
other two alternatives you list. The major feature of KCL is that it is
nearly free, but remember, Time is Money, too.
There is also a third choice: Ibuki Common Lisp, which is an improved version
of KCL. It is supposedly much more usable for development, with a lot of work
done on the debugger, etc. I don't know anything about its performance. I
don't know its price, but I suspect it's less than the other two.
There's also a fourth choice, another version of KCL, which I don't know much
about.
------- End undelivered message -------